做进销存这件事最开始是被一个开社区超市的朋友刺激到的。他店里的日用品加零食饮料差不多一千多个SKU一直用Excel记进货、用本子记流水月底盘一次库存基本要对一晚上还经常出现“系统里还有货、货架上却找不到”的尴尬情况。更头疼的是临期商品没有提醒机制全靠理货员肉眼翻。正好我在自学Python和Flask就想用这两个东西给他做一个轻量级的小型进销存系统。刚开始我以为只是写几个增删改查真正动手才发现业务逻辑里全是细节。这篇文章就完整记录一下这套基于Flask的小型超市商品进销存管理系统是怎么从需求拆解到落地上线的包含数据库设计、核心代码、部署过程以及跑了大半年之后遇到的各种坑。不管你是刚学Flask想找个练手项目还是经营小店想自己捣鼓个工具这篇都值得花几分钟读完。整个项目没有用重型框架没有复杂的前端工程就是Flask加SQLite加Jinja2模板代码量不大但五脏俱全。1. 一家小超市的账目混乱逼我写了这套系统1.1 手工管库存的典型灾难现场朋友那家超市面积不到100平米但商品种类真不少。饮料区、零食区、日用百货、调味品、冷冻食品每个大类下面又有数不清的SKU。他原来管库存的方式是这样的进货时在Excel里登记一批卖出时靠收银系统打小票但收银系统只是记录金额并没有和进货数据打通。结果就是——月底盘点时Excel里的库存数和货架上实际数量经常对不上差额少则几件多则整箱。供应商调价之后Excel里的进货价没有及时更新毛利算出来是错的。卖得快的商品忘了补货卖得慢的商品堆在角落里过了保质期。每天哪些商品贡献了多少利润完全靠猜。这种混乱不是个别现象很多小店主都有类似的痛点。市面上不是没有进销存软件但要么年费几百上千要么功能太复杂、光录入商品资料就要折腾一周对小店来说根本用不起来。1.2 做之前先想清楚系统到底要管什么朋友的需求一开始很含糊就说“帮我搞个能记进货、记卖货、看库存的系统”。我跟他聊了一个下午才把需求拆成四件事商品管理新增、编辑商品信息包括名称、规格、进货价、零售价、库存上下限。进货管理登记每批进货自动累加库存。销售管理登记卖出商品自动扣减库存同时记录销售流水。库存查询与预警随时查看当前库存数量低于下限时高亮提醒方便补货。除此之外还有一个隐藏需求就是哪怕我不在店里朋友自己在电脑上也能操作最好不用装数据库客户端打开浏览器就能用。这基本上就是Flask最擅长的场景轻量、简洁、和浏览器天然亲近。2. 业务边界划定进销存系统只该做好这四件事2.1 不要顺手做一个“大而全”的系统确定功能边界这件事比写代码重要得多。聊需求时朋友提了一堆想法要做会员积分、要做促销活动、要对接微信收款、还要老板手机看报表……我一个一个听后跟他确认了第一版只做核心闭环——管商品、管进货、管卖出、管库存。会员和促销涉及大量业务规则微信对接涉及第三方接口手机报表涉及权限设计这些在第一个版本里塞进来只会让系统死在摇篮里。我的判断是进销存的核心价值就是把“进货—库存—销售”这条数据链打通。先把这条链跑稳其他功能都是后面的加法。2.2 单人操作场景下的数据流设计店里日常操作就两类人老板也就是我朋友和一个兼职收银员。操作频率不高平均一天二三十笔销售进货可能一天一两笔。数据流非常线性进货 → 库存增加 → 销售 → 库存减少 → 低库存预警 → 再次进货这套数据流决定了系统不需要复杂的并发处理也不需要分布式缓存。一台普通电脑跑一个Flask服务完全能扛得住。如果未来的某一天门店扩张到多个收银台同时开单再考虑MySQL和更完善的事务处理也不迟。2.3 用户体验上的取舍朋友平时不太会用电脑所以界面一定要简单直接。最终方案是首页展示库存总览和低库存提醒顶部导航只有“商品管理”“进货入库”“销售开单”“销售统计”四个入口。任何操作都控制在两次点击以内表单字段尽量少。我也刻意没有用前后端分离的方案因为那样需要额外部署Node环境和API服务。直接用Flask的Jinja2模板渲染页面配一点原生JavaScript和Bootstrap样式就足够应付这个小场景了。页面刷新慢一点没关系胜在结构简单、排查问题容易。3. Flask技术选型轻量框架如何接住小超市的业务3.1 为什么是Flask而不是Django做这个项目之前我其实先看过Django。Django功能非常齐全自带Admin后台、ORM、模板引擎、表单处理几乎什么都有。但问题也就出在“什么都有”上。对一个总共五六个页面的小应用来说Django的项目结构反而显得笨重创建项目、配置settings、注册app、迁移数据库每一步都有固定套路。Flask则灵活得多。它只有一个核心路由、模板、请求响应这些最基本的东西处理得干净利落其余功能靠扩展补充。这里我用的是Flask本身负责路由、请求处理、模板渲染。Flask-SQLAlchemy数据库ORM省去手写SQL的重复劳动。SQLite文件型数据库零配置适合单机部署。Bootstrap 5 Jinja2模板做界面。整套依赖加起来只有几个requirements.txt写出来也不到一屏。3.2 SQLite够用但需要理解它的边界存储方案我选了SQLite而不是MySQL理由非常现实店里的电脑没有数据库服务装MySQL对朋友来说是个心理负担。SQLite就是单个文件Flask-SQLAlchemy连接串写一行就能用备份也简单直接复制文件就行。SQLite的边界也很清楚适合单进程写入、并发读取的高并发场景。小店一天几十笔写入SQLite完全能扛。但如果是几十个收银台同时开单或者销售数据要跨门店汇总那就得上MySQL甚至更专业的方案了。选型不追求最先进匹配实际场景就好。3.3 模板渲染是进销存系统最合适的交互方式一开始我考虑过用Vue或React做前端后来放弃了。原因很简单这个系统的操作形态是“每几分钟点一次填几个表单看结果”不是持续交互的富客户端应用。Jinja2模板渲染配合表单提交每次操作之后重新加载页面对收银员来说反而更清晰我填完单子点保存页面刷新库存数字更新这就是一次完整的操作反馈。不需要Spa的复杂状态管理也不需要为了一个数字实时更新去维护WebSocket连接。4. 数据库设计四张核心表如何兜住进销存全流程4.1 商品表所有业务的起点商品表是整个系统的基石。我设计的字段包括id主键barcode条码有些商品有可空name商品名称category分类比如饮料、零食、日用品spec规格比如“500ml/瓶”purchase_price进货价retail_price零售价stock当前库存数量low_stock_threshold低库存预警阈值create_time创建时间这里的核心设计决策是库存字段直接放在商品表中而不是通过流水表临时计算。原因很简单——查询速度快代码直观。每次进货、销售时更新这个字段同时写入流水表两头都要准。4.2 进货单和进货明细记录每一批货的来源和金额进货需要分“主表明细”两层结构。主表存进货批次信息比如进货单号、供应商、进货日期、总金额明细表存本批次的每一件商品进了多少、进价多少。这样设计的好处是一张进货单可以包含多种商品符合实际进货场景。可以按单号追溯到某一天进了哪位供应商的什么货。计算这批货的总成本时只需要汇总明细表的金额字段。进货单主表字段id、order_no进货单号、supplier供应商、total_amount总金额、create_time进货明细表字段id、order_id外键关联进货单、product_id外键关联商品、quantity数量、price进货单价4.3 销售订单和销售明细库存扣减的可追溯依据同里销售也分主表和明细两级。主表记录一笔销售单的总金额和销售时间明细表记录卖了哪几件商品、单价多少、数量多少。这个结构看起来比“只记录卖了多少总数”多几张表但换来的是极强的追溯能力月底对账时每一笔销售从哪里来、卖了多少、收了多少钱一目了然。销售订单表字段id、order_no、total_amount、create_time 销售明细表字段id、order_id、product_id、quantity、price4.4 表结构的SQL落地这些表如果用SQLAlchemy来定义大致是这样的from flask_sqlalchemy import SQLAlchemy db SQLAlchemy() class Product(db.Model): __tablename__ product id db.Column(db.Integer, primary_keyTrue) barcode db.Column(db.String(64), nullableTrue) name db.Column(db.String(128), nullableFalse, indexTrue) category db.Column(db.String(64), indexTrue) spec db.Column(db.String(128), nullableTrue) purchase_price db.Column(db.Numeric(10, 2), nullableFalse, default0) retail_price db.Column(db.Numeric(10, 2), nullableFalse, default0) stock db.Column(db.Integer, nullableFalse, default0) low_stock_threshold db.Column(db.Integer, nullableFalse, default5) create_time db.Column(db.DateTime, nullableFalse, defaultdatetime.now) class PurchaseOrder(db.Model): __tablename__ purchase_order id db.Column(db.Integer, primary_keyTrue) order_no db.Column(db.String(32), uniqueTrue, nullableFalse) supplier db.Column(db.String(128), nullableTrue) total_amount db.Column(db.Numeric(10, 2), nullableFalse, default0) create_time db.Column(db.DateTime, nullableFalse, defaultdatetime.now) items db.relationship(PurchaseItem, backreforder, lazyTrue) 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)) product_id db.Column(db.Integer, db.ForeignKey(product.id)) quantity db.Column(db.Integer, nullableFalse, default0) price db.Column(db.Numeric(10, 2), nullableFalse, default0) class SaleOrder(db.Model): __tablename__ sale_order id db.Column(db.Integer, primary_keyTrue) order_no db.Column(db.String(32), uniqueTrue, nullableFalse) total_amount db.Column(db.Numeric(10, 2), nullableFalse, default0) create_time db.Column(db.DateTime, nullableFalse, defaultdatetime.now) items db.relationship(SaleItem, backreforder, lazyTrue) class SaleItem(db.Model): __tablename__ sale_item id db.Column(db.Integer, primary_keyTrue) order_id db.Column(db.Integer, db.ForeignKey(sale_order.id)) product_id db.Column(db.Integer, db.ForeignKey(product.id)) quantity db.Column(db.Integer, nullableFalse, default0) price db.Column(db.Numeric(10, 2), nullableFalse, default0)价格字段用 Numeric(10,2) 而不是 Float是为了避免浮点数精度问题。卖东西算钱这件事差一分钱都别扭。5. 核心代码实现进货、销售、库存预警的落地写法5.1 进货入库的完整逻辑进货入库的代码不复杂但有一个关键点必须保证“写进货单”和“更新库存”这两个动作同时成功或者同时失败。如果进货单保存了库存却忘记加库存数据就永远错位了。from datetime import datetime from flask import request, redirect, url_for, flash from app import db from models import Product, PurchaseOrder, PurchaseItem def submit_purchase(): product_ids request.form.getlist(product_id) quantities request.form.getlist(quantity) prices request.form.getlist(price) supplier request.form.get(supplier, ).strip() if not product_ids: flash(进货项不能为空, danger) return redirect(url_for(purchase)) # 生成进货单号 order_no PO datetime.now().strftime(%Y%m%d%H%M%S) po PurchaseOrder(order_noorder_no, suppliersupplier, total_amount0) db.session.add(po) total 0 for pid, qty, price in zip(product_ids, quantities, prices): qty int(qty) price float(price) if qty 0 or price 0: continue product db.session.get(Product, int(pid)) if product is None: continue # 创建进货明细 item PurchaseItem(orderpo, product_idproduct.id, quantityqty, priceprice) db.session.add(item) # 累加库存 product.stock qty total qty * price po.total_amount total try: db.session.commit() flash(f进货单 {order_no} 保存成功共 {total:.2f} 元, success) except Exception: db.session.rollback() flash(进货单保存失败请重试, danger) return redirect(url_for(purchase))这里有一个细节进货单价应该取当前表单里填的价格而不是商品资料里的进货价。因为供应商经常调价现在进的这批货可能和上次进价不一样。如果直接用商品表里的旧价格就会导致成本核算失真。5.2 销售出库与库存扣减销售开单的逻辑和进货类似只是方向相反。客人买了两瓶可乐、一包薯片收银员在页面上选择商品、填数量、点保存系统生成销售单并扣减库存。def submit_sale(): product_ids request.form.getlist(product_id) quantities request.form.getlist(quantity) if not product_ids: flash(销售项不能为空, danger) return redirect(url_for(sale)) order_no SO datetime.now().strftime(%Y%m%d%H%M%S) so SaleOrder(order_noorder_no, total_amount0) db.session.add(so) total 0 for pid, qty in zip(product_ids, quantities): qty int(qty) if qty 0: continue product db.session.get(Product, int(pid)) if product is None: continue # 检查库存是否足够 if product.stock qty: db.session.rollback() flash(f商品 {product.name} 库存不足当前库存 {product.stock}, danger) return redirect(url_for(sale)) item SaleItem(orderso, product_idproduct.id, quantityqty, priceproduct.retail_price) db.session.add(item) # 扣减库存 product.stock - qty total qty * float(product.retail_price) so.total_amount total try: db.session.commit() flash(f销售单 {order_no} 保存成功金额 {total:.2f} 元, success) except Exception: db.session.rollback() flash(销售单保存失败请重试, danger) return redirect(url_for(sale))销售单价直接取商品资料里的零售价这个设计的出发点是收银场景要快不想让收银员每单都手动输入价格。如果遇到打折或者称重商品这份代码还需要再加一个“手动调整价格”的字段这是后话了。5.3 低库存预警和首页数据总览库存预警的实现非常简单查询全部商品把库存小于等于阈值的商品在首页单独列出来。我在首页专门加了一个“需要补货”的区块用表格展示商品名称、当前库存、预警阈值和最近一次进货价方便朋友安排进货计划。def home(): products Product.query.all() low_stock_list [p for p in products if p.stock p.low_stock_threshold] # 计算库存总估值 total_value sum(p.stock * float(p.purchase_price) for p in products) return render_template(home.html, productsproducts, low_stock_listlow_stock_list, total_valuetotal_value)做这个页面的时候我意识到首页不要放太多信息。这里只放了四个数字商品总数、库存总成本、低库存商品数、今日销售额再加上一张低库存商品表。信息少一眼扫过去就能知道店里什么情况。5.4 一段关于事务处理的补充说明进销存系统最关键的就是数据一致性。进货、销售操作都要经历“写主表 写明细 更新库存”三个步骤这三个步骤必须在一个事务里完成。上面代码里我把所有写操作放在同一个db.session.commit()之前遇到库存不足或异常就回滚整个事务这样就不会出现库存减了但销售单没保存的情况。SQLite本身对事务的支持是完备的但要注意一点SQLite的写锁是数据库级别的多个请求同时写时可能抛出“database is locked”的异常。Flask默认每个请求一个session如果同时有多个写请求就会触发这个异常。我的应对方法是在提交前捕获IntegrityError和OperationalError重试一次如果还不行再提示用户稍后操作。小店并发低这个策略足够用。6. 本地跑通到店里部署环境、初始化与局域网访问6.1 用VSCode搭开发环境的几个细节这个项目开发全程用的VSCode。环境配置有几个容易踩坑的地方建虚拟环境后要在VSCode里手动选择解释器命令行运行python可能还是系统环境。安装Flask-SQLAlchemy时注意版本老教程里的db.create_all()在新版本可能需要在应用上下文里执行。运行前先pip install -r requirements.txt装上依赖不要靠编辑器自动提示补包容易遗漏。一个完整的requirements.txt大概长这样Flask2.3.3 Flask-SQLAlchemy3.1.1我特意把依赖缩到最少连Flask-WTF都没用表单直接手写HTML处理。6.2 数据库初始化和测试数据填充首次运行前需要初始化数据库。我在项目里写了一个init_db.py脚本专门用来建表和写入几条测试商品数据python init_db.py脚本内部from app import app, db from models import Product with app.app_context(): db.create_all() # 写入测试数据 p1 Product(name可口可乐 500ml, category饮料, retail_price3.5, purchase_price2.8, stock50, low_stock_threshold10) p2 Product(name乐事薯片 原味 70g, category零食, retail_price6.0, purchase_price4.5, stock20, low_stock_threshold5) db.session.add_all([p1, p2]) db.session.commit()测试数据很重要否则刚打开页面一片空白朋友又不知道该从哪里开始点起。直接给他几条演示数据他就能立马体验整个流程。6.3 局域网访问配置让收银台电脑也能用店里用一台主机跑系统另一台收银电脑通过浏览器访问。Flask默认只监听127.0.0.1局域网其他机器访问不到需要在启动时把host绑定为0.0.0.0python app.pyapp.py里这样写if __name__ __main__: app.run(host0.0.0.0, port5000, debugFalse)这里有一个非常关键的坑Windows防火墙默认拦截5000端口的入站访问。第一次配置时我在收银电脑上访问http://192.168.1.100:5000怎么都打不开排查了半天才发现是防火墙没放行。解决方案是在Windows高级防火墙里添加一条入站规则允许TCP端口5000访问。还有一个细节建议用debugFalse。调试模式会暴露堆栈信息给访问者在小店的局域网场景里虽然风险不大但养成好习惯总没错。6.4 数据备份方法数据都存在SQLite文件里最简单的备份就是定期复制这个文件。我建议朋友每周拷一份到U盘或网盘文件名加上日期。更省事的方案是写个脚本用计划任务自动备份copy store.db backup_store_%date:~0,4%%date:~5,2%%date:~8,2%.db这种备份方式虽然土但在单机场景下异常可靠。数据库文件只有十几MB每天备份一次也不占地方。7. 实际运行半年的典型坑位与针对性优化7.1 并发扣库存导致的数量错位店里有三个浏览器窗口同时开单时第一次遇到了库存扣减错乱的问题。原因很简单两个请求同时读到库存为10分别扣完2件和3件后后提交的请求把库存覆盖成了7而不是5。SQLAlchemy的session并不能自动处理这个问题。我的修复方案是在扣库存前用一条带WHERE条件的UPDATE语句确保只有当stock仍等于预期值时才会更新。from sqlalchemy import update result db.session.execute( update(Product) .where(Product.id pid, Product.stock before_stock) .values(stockbefore_stock - qty) ) if result.rowcount 0: db.session.rollback() flash(库存已被其他单据修改请刷新后重试, danger) return redirect(url_for(sale))这种做法叫乐观锁适合低并发场景。虽然小店实际触发概率不高但真的碰到了就知道它有多救场。7.2 商品名称搜索的模糊匹配优化店里商品多起来以后朋友开始在销售页面用搜索框找商品。我最初用的模糊匹配写法是Product.query.filter(Product.name.like(f%{keyword}%)).all()但这条SQL在小数据量时还行商品超过五百种后明显变慢。优化方案是给name字段建了索引同时把like改成前缀优先匹配记录最常用的商品简称把它建做一个“搜索别名”字段查询时优先匹配别名其次才是全名模糊匹配。# 简化版优先搜别名其次搜名称 results Product.query.filter( db.or_( Product.alias.contains(keyword), Product.name.contains(keyword) ) ).all()这个优化对实际使用体验的提升非常直接。7.3 金额计算的精度坑项目里所有价格字段都用Numeric(10, 2)存储但Python计算总额时如果直接把Numeric类型转成float再计算多次累加后可能出现1.8000000000000002这种值。我最后的处理方式是全程用Decimal做计算只在最后格式化显示时才转字符串from decimal import Decimal, ROUND_HALF_UP total sum( Decimal(item.price) * Decimal(item.quantity) for item in order.items ) total total.quantize(Decimal(0.01), roundingROUND_HALF_UP)这个习惯在做任何涉及钱的系统时都该保留。float只能做科学计算做账得用Decimal。7.4 中文显示乱码和附件路径问题开发时还有两个小问题值得一提。一个是Windows控制台运行Flask时如果代码里有中文print需要设置环境变量PYTHONIOENCODINGutf-8否则可能报编码错误。另一个是如果未来给系统加导出Excel功能生成的临时文件一定要用os.path.join拼路径别用字符串相加Windows下路径分隔符和Linux不同线上环境常在这里翻车。7.5 关于模板安全的一个进阶提醒Flask的Jinja2模板引擎默认开启了HTML自动转义但如果你在模板里用了| safe过滤器或者把用户输入直接传给render_template_string就存在模板注入的风险。进销存系统虽然只在内网运行项目里还是保留了所有输入都要校验的习惯比如进货数量必须大于0、商品价格不能为负。这些校验看起来啰嗦实际上是防止脏数据进入系统的最好屏障。8. 一些个人体会这个项目从动手写第一行代码到店里正式用起来前后大概花了一个周末加几个晚上。写代码的时间反而不多大部分时间都花在和朋友确认需求、想清楚数据表该怎么设计、以及调试那些Windows环境下的奇怪问题上。Flask这个框架的定位非常适合这类小工具起步快、结构自由、想怎么组织代码都行。你不需要记住复杂的约定也不用理解一大堆魔法逻辑一个models.py、一个app.py、几个模板文件就能撑起一套能解决实际问题的系统。如果你也想拿一个真实项目练手Flask我非常推荐进销存这个题材。它的业务逻辑足够典型——涉及一对多关系、事务处理、搜索查询、库存计算还天然带一个“数据不能出错”的要求。把它跑通你对数据库设计和Flask开发的理解会上一个台阶。动手试一次比看十遍教程都管用。