基于Python与Flask的超市采购管理系统实现与设计

一个项目从标题命名为“基于Python基于flaskWeb的超市员工供应采购管理系统_dlhtj29a”再结合“Python、flask、Web”这三个关键词基本就能猜到它的定位一个面向高校课程设计、毕业设计或中小型超市信息化改造的Web管理系统。后缀那串字符像是自动生成的工程编号在各类开源源码站上很常见。这个系统要解决的核心问题是超市里“谁提需求、谁去采购、供应商怎么选、货到了怎么入库、库存怎么变动”这一整条供应链协作链路的数字化。现实中很多小超市还在用Excel甚至纸质单据管理采购商品信息、供应商报价、库存数量散落在不同人的电脑里对账麻烦、补货靠拍脑袋。这类系统的价值就是把这些流程统一放进一个Web应用里让员工、采购员、仓库管理员、老板在不同的权限下协同操作留下完整的数据痕迹。如果你是正在准备课程设计的学生或者刚入门Web开发想找个练手项目这个题目很典型技术栈主流、业务场景清晰、功能规模适中既能体现数据库设计能力、后端逻辑能力也能展示Web开发的完整流程。写这篇文章我就围绕这个系统从需求拆分、技术选型、数据库设计到核心功能实现完整走一遍把我在相似项目里踩过的坑和总结的经验一并放进来。1. 系统整体设计与模块划分1.1 角色与权限超市员工岗位和系统功能怎么对应做管理系统第一步永远是梳理角色和权限。不是说登录进去大家都看到一样的功能而是要让每个岗位只看到自己关心、自己能用得上的部分。这个系统里我建议至少划分四类角色超级管理员管理员工账号、维护基础数据商品分类、供应商信息、查看全部经营数据。采购员接收采购需求、创建采购单、填写采购价格和供应商信息。仓库管理员负责采购到货的验收入库、调整库存、处理报损/退货。普通员工提交采购需求、查看商品信息和个人相关的采购/入库记录。这个权限模型做出来后各角色的主页、导航菜单、可操作按钮都会有明显差异。库存数据仅对仓库管理员展示成本价对普通员工只显示名称和规格避免工资以外的定价信息过度暴露。权限控制我建议用装饰器实现不必引入复杂的权限框架。整个业务流程是这样的普通员工在前台提出采购申请经采购员审核后生成正式采购单供应商送货后仓库管理员做验收入库最后在库存表中增加对应数量同时生成一条入库流水。这样一个从需求到入库的闭环就是系统的主干功能。1.2 业务闭环设计采购需求和库存流转是怎么串起来的很多学生做这类系统容易把功能做散比如采购模块只管采购单的增删改查库存模块只管加数目两者之间没有任何联动。这是大忌。业务流程必须设计成一条完整的链。我认为核心流程是这样的链路员工在系统里提交采购需求填写商品名称、预计数量、期望到货日期。采购员在待处理需求列表中看到申请核实库存和需求合理性调整数量选择合适的供应商。系统生成采购单采购单交由供应商执行。供应商送货后仓库管理员在系统里点“入库”选择对应的采购单核对实收数量。系统自动更新商品库存表可用库存数 入库数量。同时生成入库记录关联采购单号、操作人、入库时间。实现这个闭环需要注意状态流转管理采购需求的状态有“待审核 / 已通过 / 已驳回”采购单的状态有“待下单 / 待入库 / 已完成 / 已取消”。状态值不要直接散在代码里建议在模型层定义常量比如class PurchaseStatus: PENDING 0 # 待入库 COMPLETED 1 # 已完成 CANCELED 2 # 已取消这么设计的好处是后期做统计报表时只要按状态分组聚合就能准确算出各类单据数量不会出现脏数据。我在实际项目中见过最头疼的问题就是同一业务在不同模块定义的状态值不统一导致对账时怎么都对不上。2. 技术选型与项目结构搭建2.1 为什么是Flask而不是Django或FastAPI选技术栈的时候几个框架选型逐渐被分成两派“小而美”的 Flask 和“全家桶”的 Django以及后来凭借异步和高性能走红的 FastAPI。对于这个超市供应链管理的场景我的答案是Flask最合适。理由很直接Django自带的admin后台、ORM、模板系统功能很强大但为了一个中小型管理系统整个项目结构比较重新手理解起来成本偏高。课程设计通常有开发周期限制用Flask能更快跑通。FastAPI的优势在于异步高性能和自动生成API文档适合前后端分离和接口密集型项目但对传统的服务端渲染页面FastAPI的模板和表单处理生态没有Flask成熟。Flask本身只是把HTTP请求处理和路由解决掉保留了极大的自由。你可以用Flask-SQLAlchemy管理数据库用Flask-Login做登录会话用Flask-WTF做表单校验每个组件都是独立的出了问题时定位起来非常清晰。打个比方Flask就像一间毛坯工作室想要什么功能自己往里加夹具Django则是精装修的标准工位什么都给你配好了但你想调整某个细节可能还得先学会和框架的约定共存。2.2 项目目录与代码组织建议管理系统的代码结构切记不要全部塞到一个app.py里。虽然Flask官方入门教程就是单个文件但项目一扩展几千行代码放在一个文件里连查一个函数都要滚动半天团队协作更是灾难。我推荐这样的结构supermarket_purchase/ ├── app.py # Flask 应用入口 ├── config.py # 配置文件数据库、密钥 ├── models/ │ ├── __init__.py │ ├── user.py # 员工模型 │ ├── goods.py # 商品模型 │ ├── supplier.py # 供应商模型 │ ├── purchase.py # 采购单模型 │ └── inventory.py # 库存与入库记录模型 ├── views/ │ ├── __init__.py │ ├── auth.py # 登录注册与权限 │ ├── purchase.py # 采购管理蓝图 │ ├── inventory.py # 入库管理蓝图 │ ├── goods.py # 商品管理蓝图 │ └── analytics.py # 统计图表视图 ├── templates/ # Jinja2 模板 ├── static/ │ ├── css/ │ ├── js/ │ └── images/ └── requirements.txt # 依赖清单用蓝图Blueprint来组织路由模块是Flask项目中非常推荐的实践。比如所有和采购相关的路由都放在views/purchase.py里注册时指定一个url_prefix这样路径管理与功能划分都更清晰from flask import Blueprint bp Blueprint(purchase, __name__, url_prefix/purchase) bp.route(/list) def list_purchase(): # ...主入口只需要注册蓝图from views import auth, purchase, inventory, goods, analytics app.register_blueprint(auth.bp) app.register_blueprint(purchase.bp) app.register_blueprint(inventory.bp) app.register_blueprint(goods.bp) app.register_blueprint(analytics.bp)依赖管理建议简洁明了。具体版本不锁定得太模糊至少在requirements.txt里把主版本固定住我这边比较稳的搭配是flask2.3.3 flask-sqlalchemy3.0.5 flask-login0.6.2 flask-wtf1.1.13. 数据库模型与核心关联设计3.1 五张核心表的信息模型拆解数据表设计是这类系统的地基。我按业务实体拆分建立表连接关系。员工表存登录账号、姓名、部门、角色代号、密码哈希、创建时间。密码必须用哈希绝对不许明文存储。供应商表存公司名称、联系人、联系电话、地址、合作状态。供应商跟商品是多对多关系同一个商品可能有两家供应商同一家供应商也可能供多种商品。用关联表处理更合适。商品表包括商品编码、名称、规格、单位、分类、参考进价、当前库存数量、预警阈值。商品编码设计要注意不要用自增ID做对外编码因为超市商品种类多建议用一组有意义的分级编码比如CATEGORY_NUM但初期自增ID加前缀也可以接受。采购主表存采购单号、制单人、供应商、采购总金额、状态、审核意见、创建时间。采购单号要按日期生成格式建议是PO 年月日 四位序号比如PO202401150001。采购明细表与主表关联存商品、采购单价、数量、实收数量、小计金额。库存流水表记录每次入库或出库操作包括关联采购单、商品id、变动数量、变动类型、操作人、备注。3.2 SQLAlchemy模型代码深度演示用Flask-SQLAlchemy定义模型时要特别注意表之间的外键关联与级联行为。先看关键模型的代码from flask_sqlalchemy import SQLAlchemy from werkzeug.security import generate_password_hash, check_password_hash db SQLAlchemy() class Employee(db.Model): __tablename__ employee id db.Column(db.Integer, primary_keyTrue) username db.Column(db.String(50), uniqueTrue, nullableFalse) password_hash db.Column(db.String(255), nullableFalse) fullname db.Column(db.String(50), nullableFalse) role db.Column(db.SmallInteger, default0) # 0员工 1采购 2库管 9管理员 created_at db.Column(db.DateTime, defaultdatetime.now) 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 Supplier(db.Model): __tablename__ supplier id db.Column(db.Integer, primary_keyTrue) company db.Column(db.String(100), nullableFalse) contact db.Column(db.String(30)) phone db.Column(db.String(20)) address db.Column(db.String(200)) status db.Column(db.SmallInteger, default1) # 1启用 0停用 class Goods(db.Model): __tablename__ goods id db.Column(db.Integer, primary_keyTrue) code db.Column(db.String(30), uniqueTrue, nullableFalse) name db.Column(db.String(100), nullableFalse) spec db.Column(db.String(100)) # 规格如 500ml/瓶 unit db.Column(db.String(10)) # 单位如 箱/瓶/斤 category db.Column(db.String(50)) ref_price db.Column(db.Numeric(10, 2)) # 参考进价 stock db.Column(db.Integer, default0) # 库存数量 warn_threshold db.Column(db.Integer, default10) class PurchaseOrder(db.Model): __tablename__ purchase_order id db.Column(db.Integer, primary_keyTrue) order_no db.Column(db.String(30), uniqueTrue, nullableFalse) supplier_id db.Column(db.Integer, db.ForeignKey(supplier.id)) creator_id db.Column(db.Integer, db.ForeignKey(employee.id)) total_amount db.Column(db.Numeric(12, 2), default0) status db.Column(db.SmallInteger, default0) remark db.Column(db.String(200)) created_at db.Column(db.DateTime, defaultdatetime.now) class PurchaseItem(db.Model): __tablename__ purchase_item id db.Column(db.Integer, primary_keyTrue) order_id db.Column(db.Integer, db.ForeignKey(purchase_order.id)) goods_id db.Column(db.Integer, db.ForeignKey(goods.id)) price db.Column(db.Numeric(10, 2)) quantity db.Column(db.Integer) received_qty db.Column(db.Integer, default0) # 可在这里加 line_total 的计算属性注意几个细节金额字段我用了Numeric而不是Float是因为浮点数在累计结算时会出现精度误差外键通过db.ForeignKey定义但ORM层面使用db.relationship来反向引用更方便这一点后面结合视图代码展开。3.3 为什么要建库存流水而不是直接改数字这个系统最重要的设计不要只改商品表里的stock字段还要在库存流水表里追加一行记录。比如采购入库时# 1. 更新商品库存 goods Goods.query.get_or_404(goods_id) goods.stock received_qty # 2. 写入流水 record StockRecord( goods_idgoods.id, purchase_item_iditem.id, change_qtyreceived_qty, change_type1, # 1入库 operator_idcurrent_user.id, remark采购入库 ) db.session.add(record) db.session.commit()为什么要这样做第一是审计。一旦将来库存对不上可以通过流水倒查是哪一笔操作出了问题。第二是报表。统计月度入库量、库存周转率不需要再写复杂的临时查询直接从流水表聚合就可以。第三是安全。如果只允许直接改stock字段任何人都可能背地里改数字又不留痕迹流水表相当于数据库的行级操作记录能让所有变更都有据可查。我还见过一种更严谨的方案——把流水表设计成类似于“借贷记账”的模式入库记正数、出库记负数期末汇总求和得到总库存看似费事在数据量大了之后其实非常灵活。4. 核心功能实操登录、采购、入库与数据视图4.1 登录会话与角色权限控制完整实现登录模块不用重复造轮子直接基于Flask-Login实现会话管理。流程如下from flask_login import LoginManager, login_user, login_required, current_user login_manager LoginManager() login_manager.login_view auth.login login_manager.user_loader def load_user(user_id): return Employee.query.get(int(user_id))登录视图核心代码bp.route(/login, methods[GET, POST]) def login(): if request.method POST: username request.form[username] password request.form[password] user Employee.query.filter_by(usernameusername).first() if user and user.check_password(password): login_user(user) return redirect(url_for(index)) flash(用户名或密码错误) return render_template(login.html)角色权限控制写一个装饰器from functools import wraps def role_required(*roles): def decorator(f): wraps(f) def wrapper(*args, **kwargs): if current_user.role not in roles: flash(没有权限访问该页面) return redirect(url_for(index)) return f(*args, **kwargs) return wrapper return decorator使用就非常简洁bp.route(/create, methods[GET, POST]) login_required role_required(1, 9) # 采购员和管理员可以创建采购单 def create_purchase(): # ...权限控制的红线在于服务端每次请求都要校验不能只依赖前端隐藏按钮或菜单。前端隐藏只是让用户看不见入口懂技术的人完全可以手动构造URL发起请求所以后端装饰器拦截是必须留的防线。4.2 采购单创建与明细录入表单的处理流程采购单创建是整个系统最复杂的交互天然有主表和子表两张表要同时处理。常见一次性购买多个商品所以页面结构建议是一个顶部供应商与主单信息下面一个商品明细列表每行是商品选择、数量、单价支持动态增删。视图端处理流程bp.route(/create, methods[POST]) login_required role_required(1, 9) def create_purchase(): form request.form supplier_id form.get(supplier_id) goods_ids form.getlist(goods_id[]) quantities form.getlist(quantity[]) prices form.getlist(price[]) if not supplier_id or not goods_ids: flash(请选择供应商并至少添加一件商品) return redirect(url_for(purchase.create_purchase_page)) total 0 order PurchaseOrder( order_nogenerate_order_no(), supplier_idsupplier_id, creator_idcurrent_user.id, status1 # 待入库 ) db.session.add(order) db.session.flush() # 获取 auto increment 的主键 for gid, qty, price in zip(goods_ids, quantities, prices): if not gid or not qty or not price: continue item PurchaseItem( order_idorder.id, goods_idint(gid), quantityint(qty), priceDecimal(price), received_qty0 ) db.session.add(item) total Decimal(qty) * Decimal(price) order.total_amount total db.session.commit() flash(f采购单 {order.order_no} 创建成功) return redirect(url_for(purchase.detail, order_idorder.id))表单提交有几点可以深入说明用form.getlist(goods_id[])获得同名表单项的数组这是处理动态明细的标准做法。db.session.flush()至关重要。提交主表后如果马上要在明细栏引用order.id先flush一次让数据库生成主键。如果不flushorder.id可能还是None导致插入明细时外键报错。金额统一用Decimal在Python层面累加避免中途出现浮点误差。所有价格计算在服务端完成前端输入的单价可以用字符串提交。4.3 入库登记与库存联动的实现细节采购员下单之后供应商送货仓库管理员在系统里打开待入库采购单填写每件商品的实际到货数量。可能会存在少送、多送或某些缺货的情况因此入库模块要设计成允许修改实际数量。入库提交的核心处理逻辑要在一个事务里操作bp.route(/do_receipt/int:order_id, methods[POST]) login_required role_required(2, 9) def do_receipt(order_id): order PurchaseOrder.query.get_or_404(order_id) if order.status ! 1: flash(当前订单状态不允许入库) return redirect(url_for(purchase.detail, order_idorder_id)) received_qty_map {} for item in order.items: key str(item.id) received request.form.get(freceived_{key}, typeint, defaultitem.quantity) received_qty_map[item.id] received item.received_qty received goods Goods.query.get(item.goods_id) if goods: goods.stock received record StockRecord( goods_idgoods.id, purchase_item_iditem.id, change_qtyreceived, change_type1, operator_idcurrent_user.id ) db.session.add(record) order.status 2 # 已完成 db.session.commit() flash(入库完成) return redirect(url_for(purchase.detail, order_idorder_id))这里面容易忽略的一个环节是并发操作。如果A和B两个库管同时给同一张采购单做入库会有什么结果订单状态虽然在提交时会检查但未提交前两个人拿到的都是status1可能导致库存被加两次。想要彻底防住可行方案是入库提交时给订单记录加上数据库乐观锁比如在PurchaseOrder表加一个version字段提交时检查版本号row db.session.query(PurchaseOrder).filter_by( idorder_id, versionversion).update({...})但考虑到课程设计和中小型超市的并发量通过状态判断加操作权限就足够了这里把问题提出来是让你知道设计时要考虑到这个场景。4.4 采购/库存统计报表的可视化展示一个管理系统如果只能录数据、不能看数据价值就少了一半。我建议在这个系统里加上简单的统计视图按月份汇总采购金额、按供应商比较采购占比、按商品分类显示库存分布。统计图表的生成思路很简单后端查聚合数据前端用Chart.js画图。Chart.js是纯前端的JS库不用后端单独开接口Flask模板加载后直接执行。后端用SQLAlchemy聚合查询from sqlalchemy import func, extract monthly db.session.query( func.date_format(PurchaseOrder.created_at, %Y-%m).label(month), func.sum(PurchaseOrder.total_amount).label(total) ).group_by(month).order_by(month).all()把结果传给模板后在模板中处理成图表要的数据结构return render_template(analytics/index.html, months[r.month for r in monthly], totals[float(r.total) for r in monthly])前端页面里用Chart.js代码渲染柱状图canvas idpurchaseChart height100/canvas script const ctx document.getElementById(purchaseChart).getContext(2d); new Chart(ctx, { type: bar, data: { labels: {{ months | tojson }}, datasets: [{ label: 月采购金额, data: {{ totals | tojson }}, backgroundColor: rgba(54, 162, 235, 0.6) }] }, options: { scales: { y: { beginAtZero: true } } } }); /script注意|tojson过滤器这是Jinja2里把Python列表安全转成JSON字符串的常用方法远比在HTML里写手动拼接循环要可靠得多。Chart.js直接从CDN加载就行但要注意网络建议下载后放进static/js目录内网也能正常渲染。4.5 增加条件筛选与分页查询当数据量增长采购单列表不能一次加载几百行。更好的方式是加查询条件和分页。使用Flask-SQLAlchemy的分页方法page request.args.get(page, 1, typeint) per_page 20 query PurchaseOrder.query if supplier_id: query query.filter(PurchaseOrder.supplier_id supplier_id) if status: query query.filter(PurchaseOrder.status status) pagination query.order_by(PurchaseOrder.created_at.desc()).paginate( pagepage, per_pageper_page, error_outFalse)模板里就可以用pagination.items拿到当前页的数据用pagination.iter_pages()渲染页码导航。这里有个容易踩的坑paginate(pagepage, per_page20)如果page传1但是第一页只有两行数据撑不满error_outFalse可以避免404直接渲染空列表页体验会好很多。5. 部署上线与常见问题排查5.1 本地开发环境怎么快速跑起来拿到源码后的第一件事永远是先把项目跑起来而不是去逐行读代码。通常的步骤是创建虚拟环境。Windows下用python -m venv venv然后用venv\Scripts\activate激活。Linux/Mac用source venv/bin/activate。安装依赖pip install -r requirements.txt。如果依赖安装太慢换国内镜像源比如清华的PyPI镜像。初始化数据库。对于中小系统直接用SQLite最省事也就是sqlite:///supermarket.db。执行模型创建如果项目里有create_all()直接运行初始化脚本from app import app, db with app.app_context(): db.create_all()创建初始管理员账号。一般可以在初始化脚本里加一个admin Employee(usernameadmin, fullname系统管理员, role9) admin.set_password(admin123) db.session.add(admin) db.session.commit()启动开发服务器python app.py访问http://127.0.0.1:5000。5.2 数据库选型从SQLite切换到MySQL会遇到什么问题课程设计阶段用SQLite非常方便因为零配置文件、单文件数据库、随手就能迁移。但如果你说“我们要真正给超市用”那SQLite在多人连续写入时容易出现锁冲突建议上MySQL或MariaDB。切换数据源时常见的坑连接串直接改成mysqlpymysql://user:passwordlocalhost/dbname?charsetutf8mb4。这是最容易被卡住的环节PyMySQL要记得装。字符集问题。MySQL建库时要指定utf8mb4否则存中文和Emoji会乱码。时间字段的差异。SQLite接受datetime.now()直接写入MySQL对时区敏感建议在config里配置SQLALCHEMY_ENGINE_OPTIONS的时区参数或在数据库连接串中加上time_zone08:00。批量插入提升效率。如果将来需要做大批量初始化数据用db.session.bulk_insert_mappings比逐条add快得多但这招对复合业务逻辑不适用比如需要即时获取自增主键时。5.3 常见报错和解决思路整理我把在这个项目里最常遇到的报错和解决方案整理了一张表希望对你有实际参考价值现象原因解决方案No module named flask虚拟环境没激活或依赖没安装到位重新执行pip install flask flask-sqlalchemy ...确认是在venv内操作sqlalchemy.exc.OperationalError: no such table数据库表还没创建执行db.create_all()或检查是否配置了正确的数据库URIAttributeError: NoneType object has no attribute id在db.session.add(order)后马上取order.id但没有flush在取得id前调用db.session.flush()模板渲染报jinja2.exceptions.UndefinedError视图没传对应的变量或变量名拼写错误检查render_template里的关键字参数与模板引用是否一致ImportError: cannot import name app from app循环导入问题检查app.py是否在底部导入views模块而不是views导入app提交表单后出现CSRF token missing使用了Flask-WTF但模板的表单里没加csrf_token检查模板form表单中是否有{{ form.csrf_token }}或input typehidden namecsrf_token value{{ csrf_token() }}5.4 几个值得坚持的代码习惯这里再分享几条这类项目里很实用的编码习惯视图函数尽早return不要写多层嵌套的if-else。比如验证失败直接跳转成功后统一提交事务。这样做能让异常情况集中处理代码更好读。凡是修改数据的操作尽量放在一个事务里完成。不要在一个视图里连续提交多次否则中间一步失败时前面的数据已经提交了只能手动去数据库里删脏数据。把工具函数放进utils.py。比如生成订单号、格式化日期、校验表单等公共功能收敛到一个模块多个视图到处拷贝粘贴是最容易被批评的代码坏味道。静态资源命名规范。CSS和JS文件建议按页面或者模块分类不要给每个页面写一个独立文件更不要全部写进模板的style标签。定时备份数据库。如果你是SQLite直接把.db文件复制到备份目录即可如果是MySQL用mysqldump导出一份SQL文件。真实项目里数据丢了就不是重跑一遍能解决的问题。6. 从课程设计到实际项目这个系统还能如何扩展完成这个基础的超市采购管理系统后其实还有很多可以继续进步的方向。最直接的扩展是加一个“供应商报价对比”功能。采购员创建采购单前可以先向多家供应商询价系统记录各家报价选择性价比最高的那一家。有供应商报价记录之后采购决策就有数据支撑而不是完全凭经验和个人关系。另一个值得扩展的方向是库存预警。商品表里已经有warn_threshold字段现在只是存了一个数字可以增加一个预警视图把库存低于阈值的商品自动罗列出来并关联生成补货建议的采购单草稿。可以用简单的定时任务比如APScheduler每隔一个小时扫一次库存也可以在主页仪表盘上直接展示低库存商品列表。再往后如果门店数量多起来了还可以加上多门店库存调拨功能把总仓和分店的库存差异通过调拨单来调配。这个扩展需要再加一张调拨单主表和明细表大方向上跟采购单设计非常相似迁移成本不会太高。在实际规划时这几步扩展能按这个优先级推进先做库存预警和采购单草稿联动这个对超市日常运作帮助最大再做供应商报价中心收集采购对象数据最后分阶段引入多门店调拨。每个阶段上线一个小功能比你一次性把所有功能堆上去要稳得多也方便实际使用者的反馈随时来校准需求。我在做这类系统的过程中最大的体会是管理系统拼的从来不是花哨的前端效果而是“状态管理是否严谨、流程是否闭环、数据是否可追溯”。如果能把这一套采购与库存的交互逻辑彻底想清楚、做流畅它的复用价值远比一个追求UI炫酷的页面要高。希望这篇文章能帮你把这个项目理得更顺少跑一些弯路。