简介基于Django构建的商品销售进销存系统源码包面向正在完成Python课程设计、期末大作业或希望掌握Django项目完整搭建流程的开发者覆盖商品入库、销售管理、库存盘点等典型业务逻辑。压缩包共2000个文件整体大小仅6.08MB以JavaScript、HTML/CSS等前端资源为主同时包含少量Python后台代码以及JSON、XML配置文件其中HTML/CSS负责页面展示JavaScript实现动态交互Python则承载视图与核心业务结构紧凑且层次分明。该项目曾获评审95分以上经过严格调试确保可运行压缩包随附数据库文件导入后即可快速体验完整功能也适合作为二次开发或课程设计报告的基础模板。目前已有124人学习/下载对有Django基础或正在完成同类作业的开发者具有较高参考价值。1. Django 商品销售进销存系统别急着跑迁移先看清五张表怎么联动做期末大作业也好接手一个入门级进销存 Demo 也好Django 商品销售进销存系统几乎是绕不开的选题。需求听起来简单真动手时却要在商品、库存、订单、账户四张表之间来回联动稍有遗漏就会出现库存对不上账。这套源码把采购入库、销售出库、库存动态更新和统计报表串成一条完整业务链自带数据库文件配置好就能直接跑适合需要应付结课答辩、或者想快速熟悉 Django MTV 架构的开发者。网上的同类教程很多但字段设计不过度复杂、数据库文件又能直接落地的不算多。这篇笔记按“模型 → 业务视图 → 踩坑 → 查询优化”的顺序拆完最后给你一份启动前自检清单。2. ORM 模型与数据库文件五张核心表的字段设计和迁移顺序2.1 商品表、分类表、库存表的关键字段价格别用整数数量别用 FloatField一个进销存系统能跑起来第一关是数据模型。这套源码里最核心的是五张业务表商品表、商品分类表、仓库库存表、采购入库单、销售出库单。商品表的任务最重既要存基础信息又要给库存和订单关联字段设计直接影响后面十几处视图的写法。先看商品表的核心字段class Product(models.Model): name models.CharField(max_length200, verbose_name商品名称) barcode models.CharField(max_length32, uniqueTrue, verbose_name条形码) category models.ForeignKey( Category, on_deletemodels.PROTECT, verbose_name商品分类 ) sale_price models.DecimalField( max_digits10, decimal_places2, default0.00, verbose_name销售价 ) cost_price models.DecimalField( max_digits10, decimal_places2, default0.00, verbose_name成本价 ) status models.BooleanField(defaultTrue, verbose_name是否上架) created_at models.DateTimeField(auto_now_addTrue) class Meta: db_table products ordering [-created_at]参数上最值得留意的有三处。第一sale_price 和 cost_price 都选了 DecimalField 而不是 FloatField。价格属于金额字段Float 的浮点误差在长期累计后会在毛利统计里被放大比如一笔商品进价 19.9、售价 23.8单次毛利 3.9 没问题但几千笔交易汇总后被舍入误差吃掉几毛钱财务对账时就是麻烦。max_digits10 表示整数位加小数位一共 10 位decimal_places2 保留两位小数对一般小型商超够用。如果商品单价可能超过千万再把 max_digits 调大到 12 即可。第二barcode 加了 uniqueTrue 约束。同一商品不会因为录入时条码多了一个空格而生成多条产品记录后面统计库存时也就不用反复按名称分组去重。条形码字段的索引效果在商品量过万时尤其明显列表页按条码搜索可以走数据库索引。第三category 外键用了 on_deletemodels.PROTECT。这是刻意安排分类下还有商品时删除分类会被数据库拒绝。如果改成 CASCADE删分类会把商品一起删掉库存和订单表里就会出现一堆悬空引用直接影响对账。分类表本身很简单class Category(models.Model): name models.CharField(max_length50, uniqueTrue, verbose_name分类名称) parent models.ForeignKey( self, nullTrue, blankTrue, on_deletemodels.CASCADE, verbose_name上级分类 )parent 自关联字段支持二级分类结构比如“饮料”下面挂“碳酸饮料”“果汁”。自关联在模板里渲染层级菜单时稍麻烦一点但比起单独维护分类层级树要轻量得多。期末项目做到这个深度已经能回答老师追问的“怎么实现多级分类”了。2.2 库存表为什么要单独建冗余更新比每次聚合商品表更快有些简化教程把库存数量直接写在商品表里查询确实方便但每次销售和退换货都要同时改商品记录一旦视图里漏了过滤条件数量就会串平台。这套源码把库存单独拆到 inventory 表每个商品只对应一条库存记录class Inventory(models.Model): product models.OneToOneField( Product, on_deletemodels.CASCADE, related_nameinventory ) quantity models.IntegerField(default0, verbose_name当前库存数量) safety_stock models.IntegerField(default10, verbose_name安全库存阈值) updated_at models.DateTimeField(auto_nowTrue) class Meta: db_table inventory单独建库存表的实际收益有两个。第一入库、出库、盘点三个操作只更新 inventory.quantity 一个数值无需反复 join 商品表做聚合数据量小的项目里看不出差别SKU 到几万条时速度差距是秒级。第二库存表可以独立扩展字段比如加 batch_number 批次号、warehouse 仓库位置而不用动商品主表。safety_stock 字段是给库存预警用的。出库后如果 quantity 降到阈值以下列表页通过 annotate 计算低库存标记就能高亮显示。如果把安全库存也塞进商品表商品表的字段会越加越散最终变成一张大宽表。有一点需要注意inventory 的 quantity 是 IntegerField它的值只允许整箱数变化。进货按瓶、按件、按克计量的商品在这个模型里都要统一换算成最小库存单位否则单位混乱会让库存统计完全失真。2.3 迁移顺序和数据库文件的落地migrate 的依赖链拿到手里的资源通常自带一个 SQLite 的 .db 文件。直接把它放到项目根目录确认 settings.py 的数据库配置指向它DATABASES { default: { ENGINE: django.db.backends.sqlite3, NAME: BASE_DIR / database/db.sqlite3, } }这里就有第一个容易踩的坑路径写错。我从网上下过一版项目源码里 DATABASES 配的 NAME 是BASE_DIR / db.sqlite3实际文件躺在database/子目录里启动后直接提示 no such table: products。遇到这种情况先全局搜索 .db 文件所在位置再改 NAME 路径。路径确认后先做一次迁移状态检查python manage.py migrate --checkmigrate --check只检查挂起迁移不真正执行。多数情况下新拿到的代码会提示migrate pending这表示迁移记录和当前数据库结构不同步。如果跑完 migrate 报字段冲突或表已存在说明 .db 文件已经执行过部分迁移。这时候不要直接删除表先看迁移历史python manage.py showmigrations products输出列表里会标记[X]和[ ]带[X]的是已执行过的迁移不能重跑只需要执行未标记的部分。如果某条迁移记录显示[X]但物理表结构跟 models.py 不一致说明迁移文件被改过了。处理办法是把业务表迁移重置到初始状态再重新生成python manage.py migrate products zero --fake python manage.py makemigrations products python manage.py migrate注意migrate products zero --fake只改迁移记录不回滚数据库物理表。使用前先备份 .db 文件。我在调试这套源码时迁移顺序就折腾过三次代码本身不复杂复杂的是迁移记录和物理表之间的错位。还有一点如果源码里自定义了用户表它必须在业务表之前迁移否则外键关联会失败。拆解任何 Django 项目我的习惯都是先看 app 目录下的 migrations 文件夹再打开 models.py。3. 入库出库业务逻辑从视图函数到库存数字联动3.1 采购入库视图表单校验与库存量的原子操作进销存最核心的流程是入库。采购入库单创建成功后必须同时修改 inventory 表的 quantity 值。这里最关键的是把两个数据库操作放进同一个事务里否则入库单创建成功、库存没加上这批货就会凭空消失。典型视图实现如下from django.db import transaction transaction.atomic def stock_in(request): if request.method POST: form StockInForm(request.POST) if form.is_valid(): record form.save(commitFalse) inventory Inventory.objects.select_for_update().get( productrecord.product ) inventory.quantity record.quantity inventory.save() record.operator request.user record.save() return redirect(stock_in_list) else: form StockInForm() return render(request, stock_in.html, {form: form})transaction.atomic 是 Django 的事务装饰器。视图函数里一旦抛出异常整个事务回滚入库单和库存变动都不会落库避免出现半条业务记录。select_for_update() 会在数据库层面锁住匹配的库存行防止两个并发请求同时读到旧值再各自加库存导致数据丢失。这段代码里有三个参数值得推敲form.save(commitFalse) 先不写库等库存更新和操作人赋值都完成后再保存保证一张入库单的所有副作用一次性提交。select_for_update() 必须搭配事务使用在 transaction.atomic 修饰的函数里调用它才会生成 SELECT ... FOR UPDATE 语句否则和普通 get 没有区别。record.operator request.user 把操作人写进入库单后面审计流水时可以直接按操作人筛选。在 MySQL InnoDB 引擎下select_for_update 的锁会在事务提交时自动释放不需要手动 unlock。如果用了 PostgreSQL行为类似同样是事务结束即释放。还有一个细节入库表单的 clean 方法可以提前校验入库数量是否为正整数避免负数入库把库存改反。表单层校验不过视图里那段事务代码就根本不会执行。3.2 销售出库与库存扣减F() 表达式和 select_for_update 怎么选销售出库是入库的逆向操作但多了一个约束库存不能扣成负数。如果先查库存、判断够不够、再扣减三步走两个请求同时到达时第二步都读到了同一个旧库存值两次扣减后库存变成负数。两种常见解法第一种是继续用 select_for_update 的行锁方式代码先锁库存行再判断数量是否充足足够才扣减。第二种是改用 F() 表达式做原子更新让数据库自己执行 quantity quantity - N 这个动作从根上避免并发读旧值。from django.db.models import F transaction.atomic def stock_out(request): record StockOutForm(request.POST).save(commitFalse) updated Inventory.objects.filter( productrecord.product, quantity__gterecord.quantity, ).update(quantityF(quantity) - record.quantity) if updated 0: raise ValueError(库存不足无法出库) record.save()update() 返回受影响的行数。filter 条件里加 quantity__gterecord.quantity把数量判断直接下沉到数据库 WHERE 子句数据库层面就拒绝了超额扣减。返回值 0 表示没有库存行满足条件视图抛异常让事务回滚。F() 表达式省掉了先查后改的两个网络往返性能更好但可读性不如 select_for_update 直观。这套源码里出库用的是 select_for_update 版本能清晰看到“锁库存 → 判断 → 扣减”的顺序对期末项目来说足够。生产环境如果并发量高再改成 F() 表达式版本不迟两种写法都保留在源码里注释里对照着写清楚适用场景会更好。3.3 交易流水表入库单、出库单和库存表的对账基础进销存系统里最容易被忽略的是交易流水表。商品入库、出库、盘点调整都往这张表写一条记录字段包括商品、变动数量、变动类型、操作人、时间戳还有变动后的库存快照。class StockLog(models.Model): product models.ForeignKey(Product, on_deletemodels.CASCADE) change_type models.CharField( max_length10, choices[ (in, 采购入库), (out, 销售出库), (adjust, 盘点调整), ], ) change_quantity models.IntegerField(verbose_name变动数量) stock_after models.IntegerField(verbose_name变动后库存) operator models.ForeignKey( settings.AUTH_USER_MODEL, on_deletemodels.SET_NULL, nullTrue, verbose_name操作人, ) created_at models.DateTimeField(auto_now_addTrue) class Meta: db_table stock_log流水表的价值在于对账。如果某天发现商品库存和实际盘点不一致不需要翻遍几十张入库单和出库单直接在流水表里按 product 分组求和就能锁定是哪笔操作写错了。stock_after 字段是关键它记录了每次变动完成后的最新库存回放流水时可以还原任意时间点的库存状态这笔设计在答辩时很加分。老师问“库存错了怎么查”直接说按商品 ID 过滤流水表看每一条变更前后的快照错在哪一步一目了然。4. 进销存系统常见问题排查跑不起来、页面对不上账、数据错乱4.1 静态文件全部 404DEBUG 关闭后路径失效现象runserver 下页面样式正常部署到服务器后 css、js 全部 404页面变成纯文本。原因settings.py 里 DEBUGFalse 后Django 不再由 runserver 提供静态文件必须配置 STATIC_ROOT 和 STATICFILES_DIRS并且执行 collectstatic 收集文件。解决在 urls.py 中补充开发环境静态文件路由然后确认 settings.py 的静态文件配置from django.conf import settings from django.conf.urls.static import static if settings.DEBUG: urlpatterns static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static] STATIC_ROOT BASE_DIR / staticfiles最终执行python manage.py collectstatic把各 app 下分散的静态文件集中拷贝到 staticfiles 目录。模板里引用的是{% static css/bootstrap.min.css %}浏览器请求的路径是 /static/css/...静态文件没收集到位就必然丢样式。4.2 库存变成负数判断逻辑没写错是并发没加锁现象单人操作一切正常两个浏览器窗口同时给同一商品下单后提交的请求还是能查到库存剩 1再扣一次变成 -1。原因视图先查库存再判断再 update两个请求同时到达时第二个请求在第一个 update 之前读到了旧值数据库又没有 CHECK 约束负库存被写进去了。解决扣减前加一行 select_for_update 锁行让第二个事务等第一个提交后再读库存。inventory Inventory.objects.select_for_update().get(productproduct) if inventory.quantity need: raise ValueError(库存不足) inventory.quantity - need inventory.save()如果不想改视图逻辑还可以在 inventory 表的 quantity 字段上加 CheckConstraint 做数据库兜底class Meta: constraints [ models.CheckConstraint( checkmodels.Q(quantity__gte0), namequantity_not_negative ) ]两层都上的话即便视图漏了锁数据库也会在扣成负数时报 IntegrityError。4.3 数据库文件拷进项目跑不起来迁移记录和物理表不同步现象复制 .db 文件后运行 python manage.py migrate直接提示表 products 已存在且结构不同服务起不来。原因原 .db 文件的迁移记录对应的是旧版 models.py新源码的 models.py 可能改了字段或索引物理表结构跟模型不匹配。解决先备份原库清空业务表数据再用 makemigrations 重新生成一套干净迁移并执行cp db.sqlite3 db_backup.db python manage.py migrate --fake-initial python manage.py makemigrations python manage.py migrate --fake--fake-initial表示把已经存在的表对应的迁移当作已执行只记录状态不创建表。--fake则是跳过真正执行 SQL 步骤。这两步操作都是在“表已经存在但迁移记录缺失”的场景下用跑完后再用showmigrations核对状态。这样做的代价是旧数据可能因为字段不匹配而无法读取所以备份必须在第一步就做完。4.4 模板改了不生效模板缓存或同名文件优先级现象改了一下午 HTML浏览器刷新还是旧页面。原因两种可能。其一DEBUGFalse 时 Django 会缓存模板文件修改不会实时生效其二多个 app 有同名模板文件Django 按 INSTALLED_APPS 顺序加载了先注册的那个你改的是另一个目录的文件。解决确认 TEMPLATES 配置里 APP_DIRSTrue模板目录里只保留一份同名文件。如果改了模板立刻要验证可以在 runserver 命令后带上--noreload忽略自动重载强制手动重启服务。生产环境部署时Nginx 或 uWSGI 进程不重启模板缓存也不会刷新这时候先重启服务进程再看浏览器。4.5 商品金额对不上DecimalField 之外还有时区影响现象销售汇总表里当天销售额比前台 POS 少了几百时间维度过滤数据时发现边界订单丢了。原因Django 默认 TIME_ZONE UTC数据库里存的是 UTC 时间。当日订单按本地时间过滤时凌晨 0 点到 8 点之间的订单归属到前一天汇总统计自然对不上。解决settings.py 改成TIME_ZONE Asia/Shanghai USE_TZ FalseUSE_TZFalse 时DateTimeField 直接存本地时间查询和展示都直观。如果用 USE_TZTrue 保留国际化那所有感知时间的查询都要用localtime转换from django.utils import timezone start timezone.localtime() - timezone.timedelta(days1)日常开发里这两种配置各有利弊做期末项目直接 USE_TZFalse 最简单不容易在日切时出错。5. 列表页搜索与统计报表三个让页面提速的查询优化实战5.1 用 Q 对象组合搜索名称、条码、分类一起查商品列表除了分页还需要搜索功能。低阶实现是分别写三个 if 分支每次构造一个 QuerySet代码冗长且条件难以扩展。更干净的做法是用 Q 对象把多个条件合并from django.db.models import Q def product_list(request): query request.GET.get(q, ).strip() category_id request.GET.get(category_id, ) products Product.objects.filter(statusTrue) if query: products products.filter( Q(name__icontainsquery) | Q(barcode__icontainsquery) ) if category_id: products products.filter(category_idcategory_id) paginator Paginator(products, 20) page_obj paginator.get_page(request.GET.get(page)) return render(request, product_list.html, {page_obj: page_obj})Q 对象的优势是条件可组合多个条件用 | 表示逻辑或用 表示逻辑与。iContains 在 SQL 里生成 LIKE %keyword% 查询对中文字段也能正确匹配。搜索关键词为空字符串时filter 不会追加条件不影响性能。分页参数 20 是列表页经验值。超过 20 条就翻页既控制数据库查询量也让页面渲染更流畅。get_page 和直接取 page_number 的区别在于get_page 在页码越界时不会抛 404而是自动返回最后一页对列表页更友好。5.2 用 annotate 做低库存标记别在模板里做计算进销存列表页经常要显示“低库存”状态新手习惯在模板里写{% if p.inventory.quantity p.inventory.safety_stock %} span低库存/span {% endif %}这个写法的问题在于模板每渲染一行会触发一次 inventory 查询属于典型 N1 查询。数据量小没感觉商品到几百条时列表页请求数翻倍。更稳的做法是在 ORM 查询阶段就计算好标记from django.db.models import Case, When, Value, IntegerField, F low_stock Case( When(inventory__quantity__ltF(inventory__safety_stock), thenValue(1)), defaultValue(0), output_fieldIntegerField(), ) products Product.objects.select_related(inventory).annotate(is_lowlow_stock)模板里只判断 is_low{% if p.is_low %}span低库存/span{% endif %}Case/When 是 SQL CASE WHEN 的 ORM 表达annotate 在数据库端完成计算模板渲染阶段不再产生额外查询。select_related(inventory) 用 JOIN 一次性带出库存行进一步减少查询次数。这段代码初看有点玄学习惯之后几乎所有列表页都能套用这个模式。5.3 用 aggregate 生成销售日报一条 SQL 算完月销售额统计报表的需求很固定按商品分组统计某段时段的出库数量和销售金额。低效做法是把 StockLog 全部取回 Python 循环计算数据量大时内存和 CPU 双双告急改用 aggregate 直接在数据库聚合from django.db.models import Sum, F sales_summary ( StockLog.objects.filter(change_typeout, created_at__date2025-03-01) .values(product__name) .annotate(total_qtySum(change_quantity)) .annotate(total_amountSum(F(change_quantity) * F(product__sale_price))) .order_by(-total_qty) )先按 product__name 分组再分别计算 SUM(change_quantity) 和 SUM(change_quantity × sale_price)。F(change_quantity) * F(product__sale_price) 由数据库执行乘法annotate 把它作为聚合字段。返回的 QuerySet 是字典列表可以直接json.dumps(list(sales_summary))传给前端图表库全程零额外查询。这里有个容易翻车的点change_type 用的是字符串常量 out如果历史数据里写过 OUT 或 sell这一整条 SQL 查出来的都是空。排查时先跑一条StockLog.objects.values_list(change_type, flatTrue).distinct()核对枚举值再写聚合。6. 拿到源码启动前的验证清单从零到跑通只做七步拿到这套 Django 进销存源码和数据库文件我不会马上改代码而是按固定顺序先跑一遍流程。第一步检查 Python 版本和 Django 版本python --version确认不低于 3.7pip show django确认 Django 版本和源码兼容。requirements.txt 里如果没固定版本我一般手动装 Django 4.x LTS 而不是最新版避免新版本删掉旧语法。第二步创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate pip install -r requirements.txt第三步检查数据库文件路径确认 settings.py 里的 NAME 指向了 .db 文件实际所在地然后跑python manage.py migrate --check看迁移状态。第四步创建管理员账号并启动开发服务器python manage.py createsuperuser python manage.py runserver登录后台建一个分类、一个商品手动做一次入库和一次出库确认库存数字正确变化。这一步是判断数据库文件和源码是否配套的最快方式。第五步开两个浏览器窗口同时给同一商品下单验证库存不会被扣成负数确认视图里的锁逻辑生效。第六步把 settings.py 里的 SECRET_KEY 换掉。源码包里带的 SECRET_KEY 是公开的直接部署有安全隐患随便生成一段随机字符串替换即可。第七步数据库文件备份改动前先复制一份cp db.sqlite3 db.sqlite3.backup_$(date %Y%m%d)从那以后我每次拿到一个新的 Django 项目都会强制走一遍这份清单先跑通流程再谈改需求。这套七步启动法已经把大多数启动阶段的坑拦在了门外希望帮到你。本文还有配套的精品资源点击获取
简介基于Django构建的商品销售进销存系统源码包面向正在完成Python课程设计、期末大作业或希望掌握Django项目完整搭建流程的开发者覆盖商品入库、销售管理、库存盘点等典型业务逻辑。压缩包共2000个文件整体大小仅6.08MB以JavaScript、HTML/CSS等前端资源为主同时包含少量Python后台代码以及JSON、XML配置文件其中HTML/CSS负责页面展示JavaScript实现动态交互Python则承载视图与核心业务结构紧凑且层次分明。该项目曾获评审95分以上经过严格调试确保可运行压缩包随附数据库文件导入后即可快速体验完整功能也适合作为二次开发或课程设计报告的基础模板。目前已有124人学习/下载对有Django基础或正在完成同类作业的开发者具有较高参考价值。1. Django 商品销售进销存系统别急着跑迁移先看清五张表怎么联动做期末大作业也好接手一个入门级进销存 Demo 也好Django 商品销售进销存系统几乎是绕不开的选题。需求听起来简单真动手时却要在商品、库存、订单、账户四张表之间来回联动稍有遗漏就会出现库存对不上账。这套源码把采购入库、销售出库、库存动态更新和统计报表串成一条完整业务链自带数据库文件配置好就能直接跑适合需要应付结课答辩、或者想快速熟悉 Django MTV 架构的开发者。网上的同类教程很多但字段设计不过度复杂、数据库文件又能直接落地的不算多。这篇笔记按“模型 → 业务视图 → 踩坑 → 查询优化”的顺序拆完最后给你一份启动前自检清单。2. ORM 模型与数据库文件五张核心表的字段设计和迁移顺序2.1 商品表、分类表、库存表的关键字段价格别用整数数量别用 FloatField一个进销存系统能跑起来第一关是数据模型。这套源码里最核心的是五张业务表商品表、商品分类表、仓库库存表、采购入库单、销售出库单。商品表的任务最重既要存基础信息又要给库存和订单关联字段设计直接影响后面十几处视图的写法。先看商品表的核心字段class Product(models.Model): name models.CharField(max_length200, verbose_name商品名称) barcode models.CharField(max_length32, uniqueTrue, verbose_name条形码) category models.ForeignKey( Category, on_deletemodels.PROTECT, verbose_name商品分类 ) sale_price models.DecimalField( max_digits10, decimal_places2, default0.00, verbose_name销售价 ) cost_price models.DecimalField( max_digits10, decimal_places2, default0.00, verbose_name成本价 ) status models.BooleanField(defaultTrue, verbose_name是否上架) created_at models.DateTimeField(auto_now_addTrue) class Meta: db_table products ordering [-created_at]参数上最值得留意的有三处。第一sale_price 和 cost_price 都选了 DecimalField 而不是 FloatField。价格属于金额字段Float 的浮点误差在长期累计后会在毛利统计里被放大比如一笔商品进价 19.9、售价 23.8单次毛利 3.9 没问题但几千笔交易汇总后被舍入误差吃掉几毛钱财务对账时就是麻烦。max_digits10 表示整数位加小数位一共 10 位decimal_places2 保留两位小数对一般小型商超够用。如果商品单价可能超过千万再把 max_digits 调大到 12 即可。第二barcode 加了 uniqueTrue 约束。同一商品不会因为录入时条码多了一个空格而生成多条产品记录后面统计库存时也就不用反复按名称分组去重。条形码字段的索引效果在商品量过万时尤其明显列表页按条码搜索可以走数据库索引。第三category 外键用了 on_deletemodels.PROTECT。这是刻意安排分类下还有商品时删除分类会被数据库拒绝。如果改成 CASCADE删分类会把商品一起删掉库存和订单表里就会出现一堆悬空引用直接影响对账。分类表本身很简单class Category(models.Model): name models.CharField(max_length50, uniqueTrue, verbose_name分类名称) parent models.ForeignKey( self, nullTrue, blankTrue, on_deletemodels.CASCADE, verbose_name上级分类 )parent 自关联字段支持二级分类结构比如“饮料”下面挂“碳酸饮料”“果汁”。自关联在模板里渲染层级菜单时稍麻烦一点但比起单独维护分类层级树要轻量得多。期末项目做到这个深度已经能回答老师追问的“怎么实现多级分类”了。2.2 库存表为什么要单独建冗余更新比每次聚合商品表更快有些简化教程把库存数量直接写在商品表里查询确实方便但每次销售和退换货都要同时改商品记录一旦视图里漏了过滤条件数量就会串平台。这套源码把库存单独拆到 inventory 表每个商品只对应一条库存记录class Inventory(models.Model): product models.OneToOneField( Product, on_deletemodels.CASCADE, related_nameinventory ) quantity models.IntegerField(default0, verbose_name当前库存数量) safety_stock models.IntegerField(default10, verbose_name安全库存阈值) updated_at models.DateTimeField(auto_nowTrue) class Meta: db_table inventory单独建库存表的实际收益有两个。第一入库、出库、盘点三个操作只更新 inventory.quantity 一个数值无需反复 join 商品表做聚合数据量小的项目里看不出差别SKU 到几万条时速度差距是秒级。第二库存表可以独立扩展字段比如加 batch_number 批次号、warehouse 仓库位置而不用动商品主表。safety_stock 字段是给库存预警用的。出库后如果 quantity 降到阈值以下列表页通过 annotate 计算低库存标记就能高亮显示。如果把安全库存也塞进商品表商品表的字段会越加越散最终变成一张大宽表。有一点需要注意inventory 的 quantity 是 IntegerField它的值只允许整箱数变化。进货按瓶、按件、按克计量的商品在这个模型里都要统一换算成最小库存单位否则单位混乱会让库存统计完全失真。2.3 迁移顺序和数据库文件的落地migrate 的依赖链拿到手里的资源通常自带一个 SQLite 的 .db 文件。直接把它放到项目根目录确认 settings.py 的数据库配置指向它DATABASES { default: { ENGINE: django.db.backends.sqlite3, NAME: BASE_DIR / database/db.sqlite3, } }这里就有第一个容易踩的坑路径写错。我从网上下过一版项目源码里 DATABASES 配的 NAME 是BASE_DIR / db.sqlite3实际文件躺在database/子目录里启动后直接提示 no such table: products。遇到这种情况先全局搜索 .db 文件所在位置再改 NAME 路径。路径确认后先做一次迁移状态检查python manage.py migrate --checkmigrate --check只检查挂起迁移不真正执行。多数情况下新拿到的代码会提示migrate pending这表示迁移记录和当前数据库结构不同步。如果跑完 migrate 报字段冲突或表已存在说明 .db 文件已经执行过部分迁移。这时候不要直接删除表先看迁移历史python manage.py showmigrations products输出列表里会标记[X]和[ ]带[X]的是已执行过的迁移不能重跑只需要执行未标记的部分。如果某条迁移记录显示[X]但物理表结构跟 models.py 不一致说明迁移文件被改过了。处理办法是把业务表迁移重置到初始状态再重新生成python manage.py migrate products zero --fake python manage.py makemigrations products python manage.py migrate注意migrate products zero --fake只改迁移记录不回滚数据库物理表。使用前先备份 .db 文件。我在调试这套源码时迁移顺序就折腾过三次代码本身不复杂复杂的是迁移记录和物理表之间的错位。还有一点如果源码里自定义了用户表它必须在业务表之前迁移否则外键关联会失败。拆解任何 Django 项目我的习惯都是先看 app 目录下的 migrations 文件夹再打开 models.py。3. 入库出库业务逻辑从视图函数到库存数字联动3.1 采购入库视图表单校验与库存量的原子操作进销存最核心的流程是入库。采购入库单创建成功后必须同时修改 inventory 表的 quantity 值。这里最关键的是把两个数据库操作放进同一个事务里否则入库单创建成功、库存没加上这批货就会凭空消失。典型视图实现如下from django.db import transaction transaction.atomic def stock_in(request): if request.method POST: form StockInForm(request.POST) if form.is_valid(): record form.save(commitFalse) inventory Inventory.objects.select_for_update().get( productrecord.product ) inventory.quantity record.quantity inventory.save() record.operator request.user record.save() return redirect(stock_in_list) else: form StockInForm() return render(request, stock_in.html, {form: form})transaction.atomic 是 Django 的事务装饰器。视图函数里一旦抛出异常整个事务回滚入库单和库存变动都不会落库避免出现半条业务记录。select_for_update() 会在数据库层面锁住匹配的库存行防止两个并发请求同时读到旧值再各自加库存导致数据丢失。这段代码里有三个参数值得推敲form.save(commitFalse) 先不写库等库存更新和操作人赋值都完成后再保存保证一张入库单的所有副作用一次性提交。select_for_update() 必须搭配事务使用在 transaction.atomic 修饰的函数里调用它才会生成 SELECT ... FOR UPDATE 语句否则和普通 get 没有区别。record.operator request.user 把操作人写进入库单后面审计流水时可以直接按操作人筛选。在 MySQL InnoDB 引擎下select_for_update 的锁会在事务提交时自动释放不需要手动 unlock。如果用了 PostgreSQL行为类似同样是事务结束即释放。还有一个细节入库表单的 clean 方法可以提前校验入库数量是否为正整数避免负数入库把库存改反。表单层校验不过视图里那段事务代码就根本不会执行。3.2 销售出库与库存扣减F() 表达式和 select_for_update 怎么选销售出库是入库的逆向操作但多了一个约束库存不能扣成负数。如果先查库存、判断够不够、再扣减三步走两个请求同时到达时第二步都读到了同一个旧库存值两次扣减后库存变成负数。两种常见解法第一种是继续用 select_for_update 的行锁方式代码先锁库存行再判断数量是否充足足够才扣减。第二种是改用 F() 表达式做原子更新让数据库自己执行 quantity quantity - N 这个动作从根上避免并发读旧值。from django.db.models import F transaction.atomic def stock_out(request): record StockOutForm(request.POST).save(commitFalse) updated Inventory.objects.filter( productrecord.product, quantity__gterecord.quantity, ).update(quantityF(quantity) - record.quantity) if updated 0: raise ValueError(库存不足无法出库) record.save()update() 返回受影响的行数。filter 条件里加 quantity__gterecord.quantity把数量判断直接下沉到数据库 WHERE 子句数据库层面就拒绝了超额扣减。返回值 0 表示没有库存行满足条件视图抛异常让事务回滚。F() 表达式省掉了先查后改的两个网络往返性能更好但可读性不如 select_for_update 直观。这套源码里出库用的是 select_for_update 版本能清晰看到“锁库存 → 判断 → 扣减”的顺序对期末项目来说足够。生产环境如果并发量高再改成 F() 表达式版本不迟两种写法都保留在源码里注释里对照着写清楚适用场景会更好。3.3 交易流水表入库单、出库单和库存表的对账基础进销存系统里最容易被忽略的是交易流水表。商品入库、出库、盘点调整都往这张表写一条记录字段包括商品、变动数量、变动类型、操作人、时间戳还有变动后的库存快照。class StockLog(models.Model): product models.ForeignKey(Product, on_deletemodels.CASCADE) change_type models.CharField( max_length10, choices[ (in, 采购入库), (out, 销售出库), (adjust, 盘点调整), ], ) change_quantity models.IntegerField(verbose_name变动数量) stock_after models.IntegerField(verbose_name变动后库存) operator models.ForeignKey( settings.AUTH_USER_MODEL, on_deletemodels.SET_NULL, nullTrue, verbose_name操作人, ) created_at models.DateTimeField(auto_now_addTrue) class Meta: db_table stock_log流水表的价值在于对账。如果某天发现商品库存和实际盘点不一致不需要翻遍几十张入库单和出库单直接在流水表里按 product 分组求和就能锁定是哪笔操作写错了。stock_after 字段是关键它记录了每次变动完成后的最新库存回放流水时可以还原任意时间点的库存状态这笔设计在答辩时很加分。老师问“库存错了怎么查”直接说按商品 ID 过滤流水表看每一条变更前后的快照错在哪一步一目了然。4. 进销存系统常见问题排查跑不起来、页面对不上账、数据错乱4.1 静态文件全部 404DEBUG 关闭后路径失效现象runserver 下页面样式正常部署到服务器后 css、js 全部 404页面变成纯文本。原因settings.py 里 DEBUGFalse 后Django 不再由 runserver 提供静态文件必须配置 STATIC_ROOT 和 STATICFILES_DIRS并且执行 collectstatic 收集文件。解决在 urls.py 中补充开发环境静态文件路由然后确认 settings.py 的静态文件配置from django.conf import settings from django.conf.urls.static import static if settings.DEBUG: urlpatterns static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static] STATIC_ROOT BASE_DIR / staticfiles最终执行python manage.py collectstatic把各 app 下分散的静态文件集中拷贝到 staticfiles 目录。模板里引用的是{% static css/bootstrap.min.css %}浏览器请求的路径是 /static/css/...静态文件没收集到位就必然丢样式。4.2 库存变成负数判断逻辑没写错是并发没加锁现象单人操作一切正常两个浏览器窗口同时给同一商品下单后提交的请求还是能查到库存剩 1再扣一次变成 -1。原因视图先查库存再判断再 update两个请求同时到达时第二个请求在第一个 update 之前读到了旧值数据库又没有 CHECK 约束负库存被写进去了。解决扣减前加一行 select_for_update 锁行让第二个事务等第一个提交后再读库存。inventory Inventory.objects.select_for_update().get(productproduct) if inventory.quantity need: raise ValueError(库存不足) inventory.quantity - need inventory.save()如果不想改视图逻辑还可以在 inventory 表的 quantity 字段上加 CheckConstraint 做数据库兜底class Meta: constraints [ models.CheckConstraint( checkmodels.Q(quantity__gte0), namequantity_not_negative ) ]两层都上的话即便视图漏了锁数据库也会在扣成负数时报 IntegrityError。4.3 数据库文件拷进项目跑不起来迁移记录和物理表不同步现象复制 .db 文件后运行 python manage.py migrate直接提示表 products 已存在且结构不同服务起不来。原因原 .db 文件的迁移记录对应的是旧版 models.py新源码的 models.py 可能改了字段或索引物理表结构跟模型不匹配。解决先备份原库清空业务表数据再用 makemigrations 重新生成一套干净迁移并执行cp db.sqlite3 db_backup.db python manage.py migrate --fake-initial python manage.py makemigrations python manage.py migrate --fake--fake-initial表示把已经存在的表对应的迁移当作已执行只记录状态不创建表。--fake则是跳过真正执行 SQL 步骤。这两步操作都是在“表已经存在但迁移记录缺失”的场景下用跑完后再用showmigrations核对状态。这样做的代价是旧数据可能因为字段不匹配而无法读取所以备份必须在第一步就做完。4.4 模板改了不生效模板缓存或同名文件优先级现象改了一下午 HTML浏览器刷新还是旧页面。原因两种可能。其一DEBUGFalse 时 Django 会缓存模板文件修改不会实时生效其二多个 app 有同名模板文件Django 按 INSTALLED_APPS 顺序加载了先注册的那个你改的是另一个目录的文件。解决确认 TEMPLATES 配置里 APP_DIRSTrue模板目录里只保留一份同名文件。如果改了模板立刻要验证可以在 runserver 命令后带上--noreload忽略自动重载强制手动重启服务。生产环境部署时Nginx 或 uWSGI 进程不重启模板缓存也不会刷新这时候先重启服务进程再看浏览器。4.5 商品金额对不上DecimalField 之外还有时区影响现象销售汇总表里当天销售额比前台 POS 少了几百时间维度过滤数据时发现边界订单丢了。原因Django 默认 TIME_ZONE UTC数据库里存的是 UTC 时间。当日订单按本地时间过滤时凌晨 0 点到 8 点之间的订单归属到前一天汇总统计自然对不上。解决settings.py 改成TIME_ZONE Asia/Shanghai USE_TZ FalseUSE_TZFalse 时DateTimeField 直接存本地时间查询和展示都直观。如果用 USE_TZTrue 保留国际化那所有感知时间的查询都要用localtime转换from django.utils import timezone start timezone.localtime() - timezone.timedelta(days1)日常开发里这两种配置各有利弊做期末项目直接 USE_TZFalse 最简单不容易在日切时出错。5. 列表页搜索与统计报表三个让页面提速的查询优化实战5.1 用 Q 对象组合搜索名称、条码、分类一起查商品列表除了分页还需要搜索功能。低阶实现是分别写三个 if 分支每次构造一个 QuerySet代码冗长且条件难以扩展。更干净的做法是用 Q 对象把多个条件合并from django.db.models import Q def product_list(request): query request.GET.get(q, ).strip() category_id request.GET.get(category_id, ) products Product.objects.filter(statusTrue) if query: products products.filter( Q(name__icontainsquery) | Q(barcode__icontainsquery) ) if category_id: products products.filter(category_idcategory_id) paginator Paginator(products, 20) page_obj paginator.get_page(request.GET.get(page)) return render(request, product_list.html, {page_obj: page_obj})Q 对象的优势是条件可组合多个条件用 | 表示逻辑或用 表示逻辑与。iContains 在 SQL 里生成 LIKE %keyword% 查询对中文字段也能正确匹配。搜索关键词为空字符串时filter 不会追加条件不影响性能。分页参数 20 是列表页经验值。超过 20 条就翻页既控制数据库查询量也让页面渲染更流畅。get_page 和直接取 page_number 的区别在于get_page 在页码越界时不会抛 404而是自动返回最后一页对列表页更友好。5.2 用 annotate 做低库存标记别在模板里做计算进销存列表页经常要显示“低库存”状态新手习惯在模板里写{% if p.inventory.quantity p.inventory.safety_stock %} span低库存/span {% endif %}这个写法的问题在于模板每渲染一行会触发一次 inventory 查询属于典型 N1 查询。数据量小没感觉商品到几百条时列表页请求数翻倍。更稳的做法是在 ORM 查询阶段就计算好标记from django.db.models import Case, When, Value, IntegerField, F low_stock Case( When(inventory__quantity__ltF(inventory__safety_stock), thenValue(1)), defaultValue(0), output_fieldIntegerField(), ) products Product.objects.select_related(inventory).annotate(is_lowlow_stock)模板里只判断 is_low{% if p.is_low %}span低库存/span{% endif %}Case/When 是 SQL CASE WHEN 的 ORM 表达annotate 在数据库端完成计算模板渲染阶段不再产生额外查询。select_related(inventory) 用 JOIN 一次性带出库存行进一步减少查询次数。这段代码初看有点玄学习惯之后几乎所有列表页都能套用这个模式。5.3 用 aggregate 生成销售日报一条 SQL 算完月销售额统计报表的需求很固定按商品分组统计某段时段的出库数量和销售金额。低效做法是把 StockLog 全部取回 Python 循环计算数据量大时内存和 CPU 双双告急改用 aggregate 直接在数据库聚合from django.db.models import Sum, F sales_summary ( StockLog.objects.filter(change_typeout, created_at__date2025-03-01) .values(product__name) .annotate(total_qtySum(change_quantity)) .annotate(total_amountSum(F(change_quantity) * F(product__sale_price))) .order_by(-total_qty) )先按 product__name 分组再分别计算 SUM(change_quantity) 和 SUM(change_quantity × sale_price)。F(change_quantity) * F(product__sale_price) 由数据库执行乘法annotate 把它作为聚合字段。返回的 QuerySet 是字典列表可以直接json.dumps(list(sales_summary))传给前端图表库全程零额外查询。这里有个容易翻车的点change_type 用的是字符串常量 out如果历史数据里写过 OUT 或 sell这一整条 SQL 查出来的都是空。排查时先跑一条StockLog.objects.values_list(change_type, flatTrue).distinct()核对枚举值再写聚合。6. 拿到源码启动前的验证清单从零到跑通只做七步拿到这套 Django 进销存源码和数据库文件我不会马上改代码而是按固定顺序先跑一遍流程。第一步检查 Python 版本和 Django 版本python --version确认不低于 3.7pip show django确认 Django 版本和源码兼容。requirements.txt 里如果没固定版本我一般手动装 Django 4.x LTS 而不是最新版避免新版本删掉旧语法。第二步创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate pip install -r requirements.txt第三步检查数据库文件路径确认 settings.py 里的 NAME 指向了 .db 文件实际所在地然后跑python manage.py migrate --check看迁移状态。第四步创建管理员账号并启动开发服务器python manage.py createsuperuser python manage.py runserver登录后台建一个分类、一个商品手动做一次入库和一次出库确认库存数字正确变化。这一步是判断数据库文件和源码是否配套的最快方式。第五步开两个浏览器窗口同时给同一商品下单验证库存不会被扣成负数确认视图里的锁逻辑生效。第六步把 settings.py 里的 SECRET_KEY 换掉。源码包里带的 SECRET_KEY 是公开的直接部署有安全隐患随便生成一段随机字符串替换即可。第七步数据库文件备份改动前先复制一份cp db.sqlite3 db.sqlite3.backup_$(date %Y%m%d)从那以后我每次拿到一个新的 Django 项目都会强制走一遍这份清单先跑通流程再谈改需求。这套七步启动法已经把大多数启动阶段的坑拦在了门外希望帮到你。本文还有配套的精品资源点击获取
