高校教材征订管理系统用 Flask 写后端、Vue 写前端、PyCharm 做开发这套组合我完整跑过一轮从需求梳理到部署上线大概花了三周。如果你也准备做类似的管理系统或者正在纠结 Flask 和 Django 怎么选这篇文章应该能帮你少走不少弯路。这类系统的业务痛点其实很集中每学期开学前教材科要处理几十个班级的征订表Excel 传来传去专业、班级、教材名称稍微写错一个字后续统计就全乱。再加上学生自愿购买和班级统一征订的逻辑混在一起靠人工核对非常容易出错。所以我在设计时优先想清楚一件事系统不是简单把纸质表搬到网页上而是要把班级填报—管理员汇总—教材入库—发放确认这条业务链跑通。下面我把整套系统的设计思路、核心模块、关键代码和实际踩过的坑都拆开讲项目用到的 Flask、Python、Vue、PyCharm 这些技术点会逐个落到具体场景里。无论你是计算机专业做毕业设计还是单位内部需要快速搭一套管理后台这套实现方案都有很强的参考价值。1. 项目整体设计与技术选型思路1.1 核心业务需求梳理动工之前我花了一天半做需求梳理没有一上来就写代码。高校教材征订表面看就是选书—下单—发书但实际调研后发现不同角色看到的业务完全不一样。学生端需要查看本学期培养计划对应的教材清单确认是否购买提交个人征订意向教师或教务人员需要按班级发布教材计划导入课程教材对应关系查看各班征订进度教材管理员要合并所有订单统计每种教材的征订数量生成采购清单入库后按班级发放系统管理员则要维护用户、班级、教材库、出版社信息这些基础数据。这四个角色对应的功能差异很大所以我给项目定的模块划分是基础信息管理、教材目录管理、班级征订管理、订单汇总管理、库存发放管理、数据报表六个大块。原型图上只画了二十多个页面但核心业务闭环必须完整否则后面联调阶段会出现大量返工。1.2 Flask 与 Django 怎么选我的理由项目标题里同时出现了 Flask 和 Django这是很多人在技术选型时最纠结的地方。老实说初期我也用 Django 搭过一版原型毕竟 Django 自带 Admin 后台和完整的 ORM做管理类系统非常高效。但跑通之后我放弃了原因是这个项目的场景更偏向轻量接口服务 定制化前端Django 自带的 App 结构、中间件、Admin 系统对我来说反而是额外负担。Flask 的优势主要体现在三个方面第一是轻量一个app.py就能把应用跑起来路由写法直观前后端分离时接口逻辑非常清晰第二是灵活数据库用 SQLAlchemy 还是 Peewee、认证用 session 还是 JWT都可以自己选不会被框架绑死第三是调试方便Flask 的交互式调试器在开发阶段能直接看到异常代码位置配合 PyCharm 的断点调试效率很高。当然如果项目要继续扩展成一个包含复杂的角色权限、工作流审批、内容管理的大型后台Django 的 MTV 模式和内置 ORM 确实更省力尤其是 Django 在执行查询、删除对象这些操作时有非常成熟的 API。但就高校教材征订管理系统这个规模来说Flask 足够覆盖而且代码量更少、可读性更好。最终方案定为 Flask Vue 前后端分离开发工具统一用 PyCharm。1.3 Vue 加 Element UI 的前端方案前端部分选择 Vue核心原因是组件化开发和数据驱动的特性非常适合管理后台。教材征订页面需要动态渲染班级列表、教材列表、数量输入框如果用传统 jQuery 操作 DOM代码会非常凌乱Vue 的双向绑定可以让我直接操作数据对象页面自动更新。UI 组件库选了 Element UI表格、表单、对话框、分页、消息提示这些现成组件能覆盖 90% 的后台界面需求。Vue 的生态对新手也挺友好组件传参、路由配置、axios 请求封装都有大量现成案例遇到问题很容易查到答案。我在项目里用到了 Vue Router 做页面跳转用 Vuex 管理登录状态和用户信息用 axios 做接口请求这三种组合是管理后台最常见的技术栈。Vue 环境配置里面有一个细节创建项目时我用的是 Vue CLI而不是直接手写 webpack 配置。vue create命令可以一键生成完整工程结构开发服务器自带热更新联调阶段非常舒服。后面需要打包部署时直接执行npm run build就会生成 dist 静态目录交给后端部署即可。1.4 PyCharm 的工程组织与虚拟环境PyCharm 是整个项目的主力开发工具。虽然标题里列了 PyCharm 和 Flask但很多人装完 PyCharm 直接写代码没意识到虚拟环境的重要性。我的建议是一开始就用 virtualenv 或 conda 创建独立的解释器环境每个项目的依赖互不干扰。在 PyCharm 里配置 Flask 项目时我一般这样操作新建项目时选择已有的虚拟环境解释器然后在 Settings 中找到 Project Interpreter确认 Flask、Flask-SQLAlchemy、Flask-CORS、PyMySQL 这些包已经安装。运行配置选 Flask Server设置好 target 和 working directory就可以点绿色按钮启动调试。为了方便其他成员复现环境项目根目录放了一个requirements.txt把依赖锁定到具体版本。内容大致是flask2.2.5 flask-sqlalchemy3.0.5 flask-cors4.0.0 pymysql1.0.2 itsdangerous2.1.2 gunicorn21.2.0 waitress2.1.22. 数据库设计与核心模型实现2.1 业务对象拆解数据库设计是整个系统最不能省时间的部分。我把业务里的核心对象拆成了八个用户、角色、班级、学生、教师、教材、订单、订单明细。再加上教材和班级之间的关联关系以及库存记录一共设计了十几张表。用户和角色是认证的基础学生、教师分别通过外键关联到用户表班级是征订的最小组织单位学生属于班级教师管理一个或多个班级教材表存 ISBN、书名、出版社、价格、作者这些基础信息订单表存征订学期、班级、状态、创建时间订单明细表存每笔订单下的教材品种和数量。这样拆的好处是统计报表特别好写按订单明细分组求和就是各教材的征订总量。2.2 关键数据表结构下面这几张表是我在实际开发中反复调整后确定下来的核心结构。表名关键字段说明sys_userid, username, password_hash, role, class_id, real_name统一账号表角色区分学生/教师/管理员sys_roleid, role_code, role_name权限角色表可扩展t_classid, class_name, grade, major, teacher_id班级信息表t_bookid, isbn, book_name, author, publisher, price, stock教材信息表t_course_bookid, course_name, book_id, class_id, term课程与教材关联表一个班级对应多门课t_orderid, order_no, class_id, term, status, create_time, operator征订主表状态区分待审核/已通过/已发放t_order_itemid, order_id, book_id, quantity, price订单明细表每本教材一条记录t_inventoryid, book_id, term, in_count, out_count, remain教材入库出库流水表有一处容易忽略价格字段要用DECIMAL(10, 2)不要用FLOAT。浮点类型在金额计算中会出现精度误差教材单价虽然不大但乘以几百人的数量误差会被放大。另一个细节是订单明细里冗余了 price 字段这样即使教材表价格后来调整历史订单统计依然准确。2.3 使用 Flask-SQLAlchemy 建模Flask-SQLAlchemy 是 Flask 中最常用的 ORM。我在models.py里定义模型和上面表结构一一对应。以用户和订单为例from datetime import datetime from werkzeug.security import generate_password_hash, check_password_hash from extensions import db class User(db.Model): __tablename__ sys_user id db.Column(db.Integer, primary_keyTrue, autoincrementTrue) username db.Column(db.String(50), uniqueTrue, nullableFalse) password_hash db.Column(db.String(255), nullableFalse) role db.Column(db.String(20), nullableFalse, defaultstudent) real_name db.Column(db.String(50)) class_id db.Column(db.Integer, db.ForeignKey(t_class.id)) def set_password(self, password): self.password_hash generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password) class Order(db.Model): __tablename__ t_order id db.Column(db.Integer, primary_keyTrue, autoincrementTrue) order_no db.Column(db.String(32), uniqueTrue, nullableFalse) class_id db.Column(db.Integer, db.ForeignKey(t_class.id)) term db.Column(db.String(20), nullableFalse) status db.Column(db.String(10), defaultpending) create_time db.Column(db.DateTime, defaultdatetime.now) operator db.Column(db.String(50)) items db.relationship(OrderItem, backreforder, lazydynamic)这里用db.relationship建立订单和订单明细的关联查询订单时直接通过order.items就能拿到所有明细避免手写大量 JOIN。但要注意lazy 参数默认是select在列表页查询时容易产生 N1 问题后面性能优化时我会把部分查询改成joinedload。数据库连接串放在config.py里方便切换开发环境和生产环境import os class Config: SECRET_KEY os.getenv(SECRET_KEY, your-secret-key) SQLALCHEMY_DATABASE_URI mysqlpymysql://root:passwordlocalhost/book_order_system?charsetutf8mb4 SQLALCHEMY_TRACK_MODIFICATIONS False?charsetutf8mb4这个参数必须加否则中文写入数据库很容易乱码。MySQL 建库时也要确认字符集是 utf8mb4而不是默认的 utf8。3. 后端接口开发与关键流程实现3.1 认证与权限设计前后端分离项目里登录认证一般有两种方案Session 和 Token。考虑到这个系统部署在校园内网并发量不大我选了 Session Cookie 的方式实现简单且安全性可控。登录时先校验用户名密码然后写入 sessionapp.route(/api/login, methods[POST]) def login(): data request.get_json() user User.query.filter_by(usernamedata.get(username)).first() if user and user.check_password(data.get(password)): session[user_id] user.id session[role] user.role return jsonify({code: 0, message: 登录成功, data: { id: user.id, username: user.username, real_name: user.real_name, role: user.role }}) return jsonify({code: 1, message: 用户名或密码错误})权限控制我写了一个装饰器直接标注哪个接口需要什么角色访问from functools import wraps from flask import session, jsonify def role_required(*roles): def decorator(f): wraps(f) def wrapper(*args, **kwargs): if user_id not in session: return jsonify({code: 401, message: 未登录}) if session.get(role) not in roles: return jsonify({code: 403, message: 无权限}) return f(*args, **kwargs) return wrapper return decorator使用的时候就非常简洁app.route(/api/orders/approve, methods[POST]) role_required(admin, teacher) def approve_order(): # 审批逻辑 pass这个小装饰器撑起了整套系统的权限管控。如果你希望在无状态接口下使用也可以换 Flask-JWT-Extended核心逻辑是一样的只是把 session 换成 token 放在请求头里。3.2 征订流程核心接口教材征订的核心流程是班级负责人创建征订单选择课程对应教材填写数量提交后由管理员审核审核通过后生成采购汇总。所有操作都围绕 Order 和 OrderItem 两张表。创建订单接口我做了事务处理确保主表和明细表要么同时成功要么同时回滚from extensions import db app.route(/api/orders, methods[POST]) role_required(student, teacher, admin) def create_order(): data request.get_json() class_id data.get(class_id) term data.get(term) items data.get(items) # [{book_id: 1, quantity: 50}, ...] if not class_id or not term or not items: return jsonify({code: 1, message: 参数不完整}) order Order( order_nogenerate_order_no(), class_idclass_id, termterm, statuspending, operatorsession.get(user_id) ) db.session.add(order) db.session.flush() # 获取 order.id for item in items: book Book.query.get(item[book_id]) if not book: db.session.rollback() return jsonify({code: 1, message: f教材 {item[book_id]} 不存在}) order_item OrderItem( order_idorder.id, book_idbook.id, quantityitem[quantity], pricebook.price ) db.session.add(order_item) try: db.session.commit() return jsonify({code: 0, message: 征订单创建成功, data: {order_no: order.order_no}}) except Exception as e: db.session.rollback() return jsonify({code: 1, message: f创建失败{str(e)}})生成订单号的时候我用的是日期加随机数保证唯一性import random import time def generate_order_no(): return BZ time.strftime(%Y%m%d%H%M%S) str(random.randint(1000, 9999))这个接口的前端交互是典型的主从表结构页面顶部选择班级和学期下方动态添加多条教材记录。Vue 的响应式数组可以很方便地实现items的动态增删提交时整体传过来后端一次性落库。3.3 库存逻辑与状态流转教材和普通商品不同征订单审核通过后并不代表立刻扣库存。实际业务是管理员拿到所有班级的汇总数量后统一下采购单到货后再入库。所以订单状态和库存状态要分开处理。订单状态我设置了四档pending待审核、approved已通过、issued已发放、cancelled已取消。库存流水表负责记录每次教材入库和出库剩余数量 入库总数 - 出库总数。管理员审核征订单时不直接扣库存而是进入待采购状态。财务或采购人员看到汇总数据后线下采购再到系统中做入库登记app.route(/api/inventory/inbound, methods[POST]) role_required(admin) def inbound(): data request.get_json() book_id data.get(book_id) count data.get(count) term data.get(term) inv Inventory( book_idbook_id, termterm, in_countcount, out_count0, remaincount ) db.session.add(inv) book Book.query.get(book_id) if book: book.stock (book.stock or 0) count db.session.commit() return jsonify({code: 0, message: 入库成功})这里的关键设计是Inventory表每天或每学期都会产生多条记录通过term字段区分学期统计报表时按学期过滤避免不同学期的同一本教材数据混在一起。发放教材时批量标记订单为issued同时生成出库流水。因为涉及主表、明细表、库存表三处更新我把它放在一个事务里处理保证数据一致性。实际运行中这个逻辑出问题的概率很高所以我把事务回滚后的日志打印得非常详细方便排查。4. 前端Vue页面设计与接口联调4.1 前端工程结构Vue 项目的目录结构我习惯按功能模块划分而不是按文件类型划分。管理后台的代码量不大但页面数量多按模块拆分后找代码非常快。src/ ├── api/ # 接口请求统一封装 │ ├── auth.js │ ├── book.js │ └── order.js ├── assets/ # 静态资源 ├── components/ # 公共组件 │ ├── Pagination.vue │ └── StatusTag.vue ├── router/ # 路由配置 │ └── index.js ├── store/ # Vuex 状态管理 │ └── index.js ├── views/ # 页面组件 │ ├── Login.vue │ ├── Dashboard.vue │ ├── book/BookList.vue │ ├── order/OrderList.vue │ └── order/OrderCreate.vue └── main.js路由配置要给每个页面设置 meta 信息标注需要的角色然后在路由守卫里做权限校验。这样用户直接在地址栏输入 /orders 也无法访问没有权限的页面。4.2 核心页面开发登录页的逻辑比较简单调用/api/login接口成功后把用户信息放进 localStorage同时跳转首页。但有一个细节很容易被忽略axios 默认不会携带 Cookie如果后端用的是 Session 认证前端必须开启withCredentials。import axios from axios const service axios.create({ baseURL: process.env.VUE_APP_BASE_API || /api, timeout: 10000, withCredentials: true }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) export default service教材征订页面是系统里最复杂的页面我用 Element UI 的el-table动态渲染教材列表每一行都有数量输入框和校验规则。选择班级后会调用后端接口获取该班级的课程教材清单async loadBooks() { const res await getCourseBooks({ classId: this.classId, term: this.term }) this.bookList res.data }页面上每一行维护一个quantity字段提交时把整张表的数据拼成后端需要的 items 数组。这里我踩过一个坑el-input-number组件的值默认是undefined不清空时提交到后端会被 JSON 序列化成undefined导致后端解析失败。解决办法是在提交前统一过滤把空值转为 0。4.3 与Flask联调CORS与代理前后端分离开发时Flask 默认运行在 5000 端口Vue Dev Server 运行在 8080 端口直接请求就会出现跨域问题。我用了两种方式解决开发环境用 Vue CLI 的代理在vue.config.js里配置module.exports { devServer: { port: 8080, proxy: { /api: { target: http://localhost:5000, changeOrigin: true } } } }这样前端代码里所有请求都写成/api/xxx浏览器认为请求是同源的代理服务器再把请求转发到 Flask。生产环境部署时Flask 和后端接口在同一个域名下反向代理负责将/api转发给后端Vue 构建产物交给 Nginx 直接静态服务基本不需要额外配置。如果不想用代理也可以在 Flask 里配置 Flask-CORS但那只适合简单场景。生产环境建议用反向代理避免把后端端口直接暴露出去。两种方式我都试过代理方案在开发阶段最省心CORS 方案更适合后端接口需要被多个域名调用的情况。5. 常见问题与排查技巧实录5.1 跨域问题根本解法开发阶段用代理后跨域问题基本消失但生产环境还是会遇到。一个非常隐蔽的问题是前端通过 Nginx 访问/apiNginx 将请求转发到 Flask但 Flask 生成的重定向地址或会话 Cookie 写的是后端端口。解决办法是在 Flask 配置里明确指定请求协议和域名或者使用ProxyFix中间件。我的实际做法是生产环境不让 Flask 直接处理 Session而是在 Nginx 配置里统一处理 Cookie 的域和路径后端只负责业务逻辑。5.2 数据库中文乱码中文乱码是 Flask MySQL 项目里出现频率最高的问题。排查时按三层检查第一层是新建数据库和表的字符集必须明确指定utf8mb4第二层是 SQLAlchemy 连接串必须带?charsetutf8mb4第三层是 HTTP 接口返回的 JSONFlask 的jsonify默认使用 UTF-8一般不会乱但如果手动json.dumps就需要指定ensure_asciiFalse。我还遇到过一次诡异的情况MySQL 表字符集是 utf8mb4但个别字段在建表时继承成了 latin1导致写入中文报错。这种问题不容易察觉排查的时候用SHOW CREATE TABLE t_book;查看每个字段的字符集必要时直接改字段属性。5.3 分页性能优化管理后台列表页数据量达到上万条后直接Model.query.all()会把内存吃满。我一开始的订单列表接口就是这样加载速度明显变慢。后来统一改成分页查询page request.args.get(page, 1, typeint) per_page request.args.get(per_page, 10, typeint) paginate Order.query.order_by(Order.create_time.desc()).paginate( pagepage, per_pageper_page, error_outFalse ) items [o.to_dict() for o in paginate.items] return jsonify({ code: 0, data: { items: items, total: paginate.total, page: page, per_page: per_page } })查询订单明细时记得用joinedload一次性把关联的教材信息加载出来否则每个订单明细都会单独查询一次教材表接口响应时间会成倍增加。5.4 日期和 JSON 序列化Flask 的jsonify默认不能直接序列化datetime对象会报TypeError: Object of type datetime is not JSON serializable。最简单的方式是在模型里定义to_dict()方法把日期字段手动转成字符串def to_dict(self): return { id: self.id, order_no: self.order_no, term: self.term, status: self.status, create_time: self.create_time.strftime(%Y-%m-%d %H:%M:%S) if self.create_time else None }所有接口统一调用to_dict()比写一个全局 JSONEncoder 更直观。这套系统上线后后续加字段只需要在模型里同步更新to_dict()即可。6. 部署上线经验与后续扩展6.1 使用 Waitress 用于 Windows 部署学校服务器大概率是 Windows ServerFlask 自带的开发服务器不能用于生产环境。网上很多教程让你用 Gunicorn但 Gunicorn 在 Windows 上支持不好所以我生产环境用了 Waitress纯 Python 实现安装和执行都非常简单。pip install waitress waitress-serve --listen0.0.0.0:5000 app:app如果不想用命令行也可以写一个启动脚本from waitress import serve from app import app if __name__ __main__: print(Server running on http://0.0.0.0:5000) serve(app, host0.0.0.0, port5000)实际部署时先用防火墙只开放必要端口再用 Nginx 做反向代理。Flask 应用处理静态文件的效率远不如 Nginx所以 Vue 构建出的 dist 目录交给 Nginx接口请求通过/api前缀转发到 5000 端口。Nginx 最关键的一段配置如下server { listen 80; server_name your-domain-or-ip; root /var/www/book_system/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:5000/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }try_files那行非常关键Vue Router 的 history 模式刷新页面时会请求一个不存在的路径这行配置会把所有非接口请求都指回index.html由前端路由接管。6.2 上线前必做的安全检查系统上线前我做了几件事改掉默认的 SECRET_KEY不放在代码里改用环境变量把数据库账号密码从代码中拆到.env文件给管理员账号开启强制修改初始密码对接口增加简单的请求频率限制防止暴力登录。另外文件上传功能我没有在这个系统里做因为教材征订系统基本不需要上传文件。如果后续要增加教材封面或导入 Excel需要在接口里增加文件类型和大小校验避免直接信任用户上传的文件名。6.3 这套系统还能怎么扩展坦白说这个系统做完之后教材科的使用反馈很好但真正上线后才会发现更多的需求。最常被问到的扩展方向有这几个第一是增加消息通知征订审核通过后自动通知班级负责人不用人工一个个登系统查看第二是增加统计图表用 ECharts 展示各班各学期的教材征订趋势方便制定采购计划第三是增加 Excel 导入导出把学生名单、教材清单从 Excel 批量导入减少手工录入第四是接入企业微信或钉钉的通知渠道让教师直接在手机上审批。这些扩展方向基本上都在现有表结构上就能实现不用推翻重来。这也是当初设计时坚持把订单、订单明细、库存流水分离的原因业务边界清楚后续加功能才不会到处改。整套系统做下来我最深刻的体会是技术栈本身不是难点难点在于把业务规则理解透。Flask 和 Vue 在学习曲线上已经很友好了真正容易出错的都是那些半懂不懂的细节比如事务一致性、日期序列化、跨域配置、字符集统一。把这些点守住系统就能稳定跑下去。
