手头有一个超市货品管理系统的小项目后端用Python前端用Vue开发工具是PyCharm框架选了Django或Flask。这类系统在课程设计、毕业设计、甚至小门店真实落地里都特别常见但很多朋友照着网上的零散教程搭起来不是环境装到一半崩了就是前后端联调时接口对不上。这篇文章就把整个项目从需求拆解、技术选型、环境配置到核心模块实现完整过一遍把我自己踩过的坑和验证过好用的做法都写出来希望能省下你几天的折腾时间。这篇内容适合三类人看准备做课程设计或毕业设计、需要一个能演示能答辩的完整项目的在校学生想给自家小超市或便利店做一套进销存工具的店主或独立开发者以及刚学完Python基础、想通过一个真实Web项目把Django、Vue、数据库串起来练手的新手。看完你不仅能跑起来一套系统还能理解每个模块为什么要这么设计出问题时知道去哪里排查。1. 系统功能拆解与整体方案设计1.1 超市货品管理系统的真实需求是什么做系统前先别急着写代码先把业务方哪怕这个业务方就是你自己的需求问清楚。超市货品管理系统听起来是个大词拆开看其实核心就三件事货品资料怎么管、进出货和销售流水怎么记、库存和钱怎么对得上。以中小型超市为场景我通常会把这些需求归纳成几个模块。货品管理管的是商品档案包括商品编号、名称、条形码、分类、进价、售价、库存上下限、供应商信息入库管理记录每一批货品进来时的数量、进价、供应商、入库时间销售管理则是前台收银或后台录入销售单的核心要能按商品条码快速找到商品、计算金额、生成销售流水库存管理要能实时看到每个商品的当前库存低于下限时报警提示统计报表要能按天、按月查看销售额、利润、商品销量排行这是店主最关心的数据。再往后还可以扩展会员管理、过期预警、多门店支持但第一版能把上面这些做扎实就已经很完整了。有一个很容易被忽略的点超市系统的核心难点不在“CRUD”增删改查而在“库存数量的一致性”。每次入库要增加库存每次销售要扣减库存如果多个收银台同时操作扣减时没做好事务控制库存就会越卖越对不上。这个点在后端接口设计时要特别注意后文我会专门讲。1.2 为什么选择Python Vue这套组合选择技术栈的核心逻辑是“团队熟悉度 业务匹配度 生态成熟度”而不是“哪个框架最火”。Python是很多学生和独立开发者最熟悉的后端语言语法简单Django和Flask都有非常成熟的ORM对象关系映射和数据库迁移方案写业务逻辑效率很高。Vue作为前端框架上手曲线比React平缓中文文档完善配合Element UI这类组件库能很快搭出后台管理界面。整个系统前后端分离后端专注提供API前端专注页面交互结构和职责都清晰后期也方便扩展。这套组合适合什么场景课程设计、毕业设计、中小型连锁超市的信息化改造演示、以及预算有限但需要一套内部管理工具的小商户。但如果你的目标是做一个高并发、日均几万订单的电商级系统那Python Vue的常规部署方案不是最优选应该考虑更重的微服务架构或直接买成熟的商用SaaS系统。工具要匹配场景这是我一直强调的。1.3 前后端分离架构怎么设计这套系统的架构非常标准前端是Vue单页应用跑在开发服务器的8080端口后端是Django或Flask写的RESTful API跑在8000端口数据库用SQLite起步部署到正式环境换MySQL代码基本不用大改。前端通过HTTP请求调用后端接口数据格式统一用JSON。前端Vue项目内部按“视图-组件-路由-状态”组织。登录页、商品管理页、销售收银页、库存报表页各自是独立的视图组件Vue Router负责页面跳转Axios负责发请求。为了避免每个组件都重复写请求代码我会封装一个统一的request工具模块把baseURL、超时时间、请求拦截器自动带token、响应拦截器统一处理错误码都配置好。后端Django侧项目结构按应用app拆分比如goods_app管商品档案、stock_app管库存流水、sale_app管销售订单、user_app管登录和权限。Flask侧则用蓝图Blueprint做同样的模块化拆分。接口地址要遵循RESTful风格比如GET /api/goods/获取商品列表POST /api/goods/新增商品DELETE /api/goods/1/删除ID为1的商品。统一的接口风格能让前后端联调时少很多沟通成本。1.4 用Django还是Flask怎么选这是被问得最多的问题直接说我的结论如果是新项目、并且预计业务逻辑会持续增加优先选Django如果只想快速写一个小服务、或者你更想灵活掌控每个组件选Flask。Django的特点是大而全。它自带Admin后台、用户认证、ORM、迁移工具、表单处理甚至自带一套后台管理系统光Admin就能直接用来录商品数据。自带Admin后台对开发效率的帮助是巨大的——你不需要先花半天写商品管理和用户管理模型一定义Admin页面就能增删改查了。Django的ORM也比SQLAlchemyFlask常用的ORM更容易上手迁移命令makemigrations/migrate是全自动的对新手极其友好。缺点也很明显框架太重很多机制比如中间件、信号、CSRF初学者理解起来有门槛。Django的 request/response流程比较固定想做一些非常定制化的小接口时感觉“被框架按住了”。Flask的特点是轻量灵活。核心就一个路由和WSGI你要什么库自己装数据库用SQLAlchemy还是直接裸SQL自己定登录认证用Flask-Login还是JWT自己选。写几个小接口时体验非常爽代码一目了然。但项目一复杂就得自己把项目结构规范好否则容易越写越乱。Flask 3.0之后对异步的支持也好了这一点和FastAPI比还是差一点后文会提。如果你已经陷入选择困难我的建议很直接以课程设计、毕业设计、或你想尽量少折腾就拿下一个完整可用系统为目标选Django。如果你已经有Flask基础或者项目确实不大十几个接口就能覆盖选Flask也完全没问题。这篇文章后文的示例代码我会以Django为主同时在很多环节点出Flask对应怎么做两套方案都能跑起来。2. 开发环境搭建与工具链配置2.1 Python和PyCharm的环境准备建议正式开始前先把环境装对这是新手最大的痛苦来源。Python版本建议3.9到3.12之间不要太老也不要追最新热搜的3.13。原因很简单很多第三方库尤其是后续要用的数据库驱动、加密库对新版本Python的wheel支持会滞后装包时报错会很折腾。在官网下载安装包安装时务必勾选“Add Python to PATH”这步漏了命令行里会找不到python命令。PyCharm这边直接说结论做这个项目用社区版Community就完全够了。社区版免费、安装包小、该有的代码补全和调试功能都有处理Python后端开发很舒服。专业版Professional的优势在前端Vue和数据库工具但Vue部分你可以用VS Code代替数据库用Navicat或DBeaver免费版就能解决没必要一上来就花钱。用PyCharm打开项目文件夹后需要给项目配置解释器建议用虚拟环境Virtualenv这样每个项目的依赖互相不干扰同一个电脑上几十个项目也乱不了。2.2 Python虚拟环境与依赖管理实操创建虚拟环境有两种方式我喜欢直接用命令行操作清晰且可控。打开PyCharm终端在项目根目录执行python -m venv venv然后激活虚拟环境。Windows下命令是venv\Scripts\activateMac/Linux下是source venv/bin/activate激活成功后命令行前面会出现(venv)标记说明你已经在这个项目的独立Python环境里了。之后安装的Django、Flask、Pillow等库都只装在这个环境里不会污染全局。依赖管理的标准做法是用requirements.txt。每次装完常用库我会立刻执行pip freeze requirements.txt把当前环境的依赖快照保存下来。换电脑、换环境时一条命令就能还原pip install -r requirements.txt这里有一个经验不要随便pip install很多接触Python不久的朋友会看到教程里有个包就装结果依赖冲突、版本混乱。正确姿势是先确定版本再安装比如Django装4.2 LTS版本长期支持版因为5.x刚发布时第三方组件兼容性不一定到位LTS版本出问题也更容易搜到解决方案。安装命令pip install django4.22.3 Django项目脚手架初始化环境准备好后用Django官方提供的命令创建项目。打开终端先确认你在虚拟环境里django-admin startproject supermarket cd supermarket python manage.py startapp goods python manage.py startapp sale python manage.py startapp stock python manage.py startapp user这里有个命名习惯项目名和app名都用小写字母、下划线分隔不要用大写后面配置URL和导入模块时能少很多坑。startproject生成的是外层项目配置目录包含settings.py、urls.pystartapp生成的是一个个功能模块目录。你后面写的核心业务代码基本都在app目录里而项目的settings配置和总路由都在外层目录。新建完app后有一件事不能漏到settings.py里的INSTALLED_APPS列表把你创建的app名字逐个加进去。漏了这步的话后面执行数据库迁移时会提示“表不存在”或模型无法识别这个错误太经典了。INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, rest_framework, corsheaders, goods, sale, stock, user, ]看到里面的rest_framework和corsheaders了吗这是后面写API和解决跨域问题要用的库需要先安装pip install djangorestframework django-cors-headers2.4 Vue项目创建与Element UI引入前端用Vue 2还是Vue 3很多人问。我的建议直接上Vue 3搭配Vite构建工具。Vite比Vue 2时代的Webpack快太多开发时热更新几乎是秒级体验完全不一样。用官方工具创建项目npm create vitelatest frontend -- --template vue cd frontend npm install npm install vue-router4 axios element-plus这里需要提前装好Node.js建议版本16以上Vite对Node版本有要求太老的Node装Vite会直接失败。安装Node的时候同样要勾选加入PATH否则npm命令找不到。依赖装完后在main.js里引入Element Plus和路由import { createApp } from vue import ElementPlus from element-plus import element-plus/dist/index.css import router from ./router import App from ./App.vue const app createApp(App) app.use(ElementPlus) app.use(router) app.mount(#app)Element Plus是Vue 3的组件库提供表格、表单、弹窗、消息提示等现成组件。用它的理由很实际后台管理系统的90%页面都是表单加表格自己手写样式既要写CSS又要处理各种交互细节用组件库能省非常多时间而且外观统一、稳定。另一个备选是Ant Design Vue风格更偏企业级但Element Plus的中文社区更活跃遇到问题好搜。3. 数据库模型设计与核心接口实现3.1 商品、库存、销售三大核心表怎么设计数据库设计是整个系统的地基。设计原则是先分清实体和关系再根据业务操作去反推字段够不够。实体有商品Goods、分类Category、供应商Supplier、入库单StockIn、入库明细StockInItem、销售订单SaleOrder、销售明细SaleItem、用户User。用Django的模型类来定义商品模型示例from django.db import models class Category(models.Model): name models.CharField(max_length50, uniqueTrue) class Meta: db_table category verbose_name 商品分类 class Goods(models.Model): code models.CharField(max_length32, uniqueTrue, verbose_name商品编码) barcode models.CharField(max_length32, nullTrue, blankTrue, verbose_name条形码) name models.CharField(max_length128, verbose_name商品名称) category models.ForeignKey(Category, on_deletemodels.PROTECT, verbose_name分类) spec models.CharField(max_length64, blankTrue, verbose_name规格) unit models.CharField(max_length16, verbose_name单位) purchase_price models.DecimalField(max_digits10, decimal_places2, verbose_name进价) sale_price models.DecimalField(max_digits10, decimal_places2, verbose_name售价) stock_lower_limit models.IntegerField(default0, verbose_name库存下限) stock_upper_limit models.IntegerField(default9999, verbose_name库存上限) create_time models.DateTimeField(auto_now_addTrue, verbose_name创建时间) def __str__(self): return self.name class Meta: db_table goods verbose_name 商品代码里有几个细节要解释。price字段用DecimalField而不用FloatField是因为浮点数在计算机里是二进制表示的0.1加0.2会变成0.30000000000000004金额算错哪怕一分钱在超市场景都是大事。DecimalField用十进制精确存储做金额计算才可靠。on_deletemodels.PROTECT的意思是如果这个分类下还有商品不允许直接删除分类防止误删导致商品变成“无头数据”。barcode允许为空因为散称商品和自制商品可能没有条码。库存表这里不直接存一个“当前库存”字段在商品表里而是设计库存流水表这是我认为整个系统最值得借鉴的设计思路。流水表记录每次库存变动的方向入库/销售/盘点调整、变动数量、变动后结存、关联单据号和操作时间。真正需要当前库存时用Django的聚合查询汇总流水或者在每次变动后同步更新一个current_stock字段。为什么这么做因为流水是不可篡改的事实记录出问题能追溯“当前库存”只是一个可以重新计算的派生值。如果只存一个数字卖错了、入库录错了你根本不知道这个数字是怎么来的。销售订单表要注意的是主表存订单头订单号、总金额、收银员、下单时间明细表存订单里的每一条商品哪个商品、单价、数量、小计。订单头和明细是1对多的关系用外键关联。为什么分开因为一张订单可能包含几十种商品如果所有信息塞一个表数据冗余严重且难以扩展。3.2 Django REST Framework写商品管理接口用Django REST FrameworkDRF写API接口非常成熟模型序列化、视图集、路由全都能省不少代码。以商品清单和新增为例完整流程分三步写序列化器、写视图集、注册路由。序列化器的作用是把Django模型转换成JSON同时负责校验前端传入的数据。商品序列化器from rest_framework import serializers from goods.models import Goods class GoodsSerializer(serializers.ModelSerializer): category_name serializers.CharField(sourcecategory.name, read_onlyTrue) class Meta: model Goods fields [id, code, barcode, name, category, category_name, spec, unit, purchase_price, sale_price, inventory]分类的id前端在表单里提交分类的名字用户在表格里展示所以用source字段把关联分类的名字透出来给前端这样表格组件直接显示category_name省得前端还要循环查分类表。视图集我习惯用ModelViewSet它把列表、新增、详情、更新、删除的标准逻辑都封装好了from rest_framework.viewsets import ModelViewSet from goods.models import Goods from goods.serializers import GoodsSerializer class GoodsViewSet(ModelViewSet): queryset Goods.objects.all().order_by(-id) serializer_class GoodsSerializer def get_queryset(self): keyword self.request.query_params.get(keyword, ) if keyword: return Goods.objects.filter( models.Q(name__icontainskeyword) | models.Q(barcode__icontainskeyword) ).order_by(-id) return self.querysetget_queryset里做的是搜索功能前端传个keyword参数过来后端按商品名称或条码模糊搜索。这是超市收银台最常用的需求——扫条码或者输几个字就能带出商品。路由注册在项目的urls.py里from django.contrib import admin from django.urls import path, include from rest_framework.routers import DefaultRouter from goods.views import GoodsViewSet router DefaultRouter() router.register(rapi/goods, GoodsViewSet) urlpatterns [ path(admin/, admin.site.urls), path(, include(router.urls)), ]DRF的DefaultRouter会自动为GoodsViewSet生成这几组接口GET /api/goods/列表、POST /api/goods/新增、GET /api/goods/1/详情、PUT /api/goods/1/更新、DELETE /api/goods/1/删除。这些接口同时满足前端Vue的表格展示、新增弹窗、编辑弹窗、删除按钮的全部需要。换到Flask环境你的工作量就是手动写对应路由和视图函数逻辑其实差不多。这里有一个新手容易卡住的地方POST请求提交数据时如果前端传了商品分类的id值后端怎样自动关联分类对象答案是DRF会自动把primary key转换成对应的模型实例你只需要保证前端传的id在分类表里真实存在。但要注意商品编码code设置为unique如果新增时重复提交了同一个编码DRF会返回400错误并提示“该字段必须是唯一的”前端要在表单提交前做好编码重复的前置校验别把错误留给数据库报。3.3 销售下单接口与库存事务处理销售是整套系统的核心业务也是最容易出并发问题的地方。销售下单接口要做的事情可以拆成几步接收前端传来的订单数据包括订单头信息和商品明细列表校验商品是否存在、购买数量是否为正整数、库存是否充足计算订单总金额不能信任前端传的总金额后端必须用数据库里的售价重新计算扣减库存保存订单。关键点在扣减库存这一步。同一时刻可能有两个收银员都在卖同一款矿泉水如果两个请求同时读到库存是100各自扣掉1瓶库存最后结果是99而不是98这就是经典的并发超卖问题。我用Django的select_for_update()来解决作用是对查询到的商品行加锁数据库行锁在当前事务提交前其他事务的更新操作必须等待。示例代码from django.db import transaction from django.db.models import F transaction.atomic def create_sale_order(request_data, operator): items_data request_data[items] order SaleOrder.objects.create( order_noSO202400001, total_amount0, operatoroperator, statuspaid ) total 0 for item in items_data: goods Goods.objects.select_for_update().get(iditem[goods_id]) if goods.current_stock item[quantity]: raise ValueError(f商品 {goods.name} 库存不足) goods.current_stock F(current_stock) - item[quantity] goods.save() SaleItem.objects.create( orderorder, goodsgoods, quantityitem[quantity], pricegoods.sale_price, subtotalgoods.sale_price * item[quantity] ) total goods.sale_price * item[quantity] order.total_amount total order.save(update_fields[total_amount]) return order代码里的transaction.atomic是事务装饰器作用是把函数整体包在一个数据库事务里任何一个步骤失败之前的所有数据库操作全部回滚不会出现“订单建了但库存没扣”的中间状态。F(current_stock)是数据库级的原子操作它把“读出来-减1-写回去”的过程合并成数据库内部的一条UPDATE语句进一步降低并发冲突概率。这里顺便提一下Flask环境下怎么做。Flask的SQLAlchemy也有类似的with_for_update()方法和事务支持逻辑一样只是写法略有差异。事务和行锁是销售类系统的命门无论用什么框架这两件事都不能省。3.4 前端Vue页面怎么对接后端API前端开发中最重要的两个文件一个是封装Axios请求的工具模块一个是各个业务页面。Axios工具模块我通常这样写import axios from axios import { ElMessage } from element-plus const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response response.data, error { ElMessage.error(error.response?.data?.detail || 请求失败) return Promise.reject(error) } ) export default request重点讲一下baseURL为什么写/api而不是http://localhost:8000。因为在开发环境后端跑在8000端口前端跑在5173端口直接请求后端会触发跨域问题。最简单的适配方案是在Vite的配置文件里配开发代理server: { proxy: { /api: { target: http://localhost:8000, changeOrigin: true } } }这样前端的请求/api/goodsVite开发服务器会转发给后端的http://localhost:8000/api/goods。生产部署时再用Nginx做同样的路径转发代码里不用改一行。这个方案比在Axios里直接写死后端地址、再依赖后端开CORS要干净得多。商品管理页面用Element Plus的el-table展示数据用el-dialog做新增和编辑这个套路学会了后面入库单、销售单页面都是同一个模式。表格列配置的核心是prop对应后端返回的字段名举个例子el-table :datagoodsList stripe border el-table-column propcode label商品编码 width120 / el-table-column propname label商品名称 min-width180 / el-table-column propcategory_name label分类 width120 / el-table-column propsale_price label售价 width100 / el-table-column label操作 width180 template #default{ row } el-button clickopenEdit(row)编辑/el-button el-button clickonDelete(row)删除/el-button /template /el-table-column /el-table这里用到的v-model、模板插槽slot、事件绑定都是Vue 3的高频知识点。页面加载时调用const fetchList async () { const data await request.get(/goods/, { params: { keyword: searchKeyword.value } }) goodsList.value data.results || data }如果后端用的是DRF的DefaultRouter分页默认开启的话返回结构是{count: 总条数, results: 当前页数据}拿到数据后记得取出results。如果不想要分页可以在Django REST settings里把分页类设为None或者让前端传page_size参数这个根据实际需求调整。4. 超市系统常见难点与排查技巧4.1 库存对不上账的排查思路在超市系统里库存和实际盘点数量对不上几乎必然会发生。排查思路是先判断问题出在“数据没写对”还是“数据被并发搞乱”。我自己的排查顺序是这样先导出库存流水看每一笔出入库记录的时间和数量是否合理再检查销售订单里有没有“订单存在但库存流水缺失”的情况通常是事务没提交成功异常被吞了然后特意找几个热销商品对比它们的并发销售测试。如果确实查到了漏记或错记要在系统里加“库存调整单”功能让管理员手动修正然后备注清楚调整原因保留可追溯性。预防方面比排查更重要。入库、销售、盘点调整这三类操作都要写库存流水并且要在一个事务里完成主表操作和流水记录。接口层还要加一层基础校验比如销售数量不能大于库存入库数量不能为负数。这类校验既要在前端表单做用户体验好更要在后端接口做数据安全的最后防线。4.2 前后端联调时的跨域和接口路径问题联调阶段高频出现的报错大概有几种。跨域报错通常会出现在浏览器控制台提示CORS policy解决方法就是我前面说的Vite代理方案或者在后端Django安装django-cors-headers并配置白名单。404通常是路径不对DRF的router注册是api/goods前端请求写成了api/goods/注意DRF默认要求末尾带斜杠反过来Flask默认不带斜杠这个细节会让新手卡很久。请求接口报403优先检查后端是否开启了CSRF验证前后端分离项目要在Django的settings里把CSRF中间件对API请求做豁免处理或者使用token认证时一并处理掉。一个很实用的联调技巧是打开PyCharm的调试模式在后端视图函数里打断点前端操作时看请求有没有进到后端、参数长什么样、数据库查出来什么结果。绝大多数前后端联调问题一打调试就明白了比自己瞎猜效率高得多。我之前带朋友做项目他花了两个晚上对着浏览器控制台排查一个“明明显示了成功却数据不刷新”的问题后来发现是前端列表没重新请求接口可见问题大多不在后端。4.3 登录认证和权限控制的简洁实现超市系统虽然是小系统但“谁能用”这件事不能含糊。管理员能看报表、改价格收银员只能开销售单如果权限全放开员工误操作改错进价真的很麻烦。最轻量可靠的方案是JWTJSON Web Token流程是用户输入账号密码后端验证通过后签发一个带过期时间的token前端把token存在localStorage里每次请求在请求头带上后端写一个认证类解析token成功后把当前用户信息挂到request上然后接口视图里判断用户角色是否满足权限。DRF配合djangorestframework-simplejwt库实现JWT很成熟两行配置就能启用token刷新机制。前端的路由守卫也在登录判断上加了一道关卡本地没有token或token快过期时一律重定向到登录页避免用户直接输URL绕过页面。Flask下则用PyJWT自己写一个认证装饰器逻辑不复杂就是签名验证加用户查询。不过如果你用的是Flask我更推荐直接上Flask-JWT-Extended这个库处理过期、刷新、黑名单都省心。4.4 采购入库设计的细节把控入库单的设计是整个供应链流程里最容易遗漏细节的地方。一张正常入库单的核心字段包括入库单号、供应商、入库日期、操作人、入库明细。入库的商品要记录采购单价、数量、生产日期如果有保质期管理需求、有效期。入库操作的后端逻辑重点在事务性保存入库单主表保存入库明细逐条增加商品库存写入库存流水这四步必须全部成功或全部回滚。还经常会有“入库时发现供应商送来的货和下单数量对不上”的情况所以设计入库明细时一定要支持修改数量而不是写死为订单数量。入库后价格对成本的影响也很关键同一种商品两次进货的进价可能不同销售毛利怎么算我建议按移动加权平均法处理即用库存总成本除以库存总量算出当前平均成本销售出库时把这个平均成本作为成本带进毛利计算。这个算法不复杂但比“用最近一次进价作为所有库存成本”要准确得多。4.5 销售报表统计的SQL和ORM写法销售报表是老板每天都要看的页面核心数据有三个当日销售额、当日订单数、销售排行。用Django ORM的聚合函数实现非常简洁from django.db.models import Sum, Count from django.db.models.functions import TruncDate today_orders SaleOrder.objects.filter(create_time__datetoday) total_sales today_orders.aggregate(totalSum(total_amount))[total] or 0 order_count today_orders.count() # 商品销售排行 top_goods SaleItem.objects.values(goods__name) \ .annotate(total_qtySum(quantity), total_amountSum(subtotal)) \ .order_by(-total_qty)[:10]这个查询value(goods__name)的目的是按商品名分组annotate对每个分组计算总销售数量和总销售额order_by倒序取前十就是热销榜单。类似地按月统计销售额只要把TruncDate换成TruncMonth即可。新手经常想用纯Python循环去算报表数据量小的时候没问题但一个月几千条订单后就明显慢了。SQL里能聚合的尽量在数据库层算完再返回既快又省内存。DRF的响应时间如果超过几百毫秒大概率是查询没有优化优先检查有没有N1问题——即循环查询每条的关联对象应该用select_related或prefetch_related一次性把关联数据查出来。4.6 从开发环境到正式部署的关键切换项目做完要给别人演示或者放到服务器上给店员用这里面隐藏着几个和环境相关的坑。数据库要从SQLite切换成MySQL或PostgreSQL。Django的ORM把大多数SQL差异屏蔽了但settings里的数据库配置要改还要pip安装对应的驱动MySQL用mysqlclientPostgreSQL用psycopg2。尤其注意有时Django项目在SQLite下跑得好好的切到MySQL后报错多半是字段类型差异或MySQL版本问题不是代码问题。前端要构建成静态文件。执行npm run build后Vite会把页面打包成dist目录下的静态文件HTML、JS、CSS。生产环境把这些静态文件交给Nginx托管然后把API请求通过Nginx反向代理到后端的Gunicorn或uWSGI服务上。Nginx配置的关键片段server { listen 80; server_name your-domain.com; root /path/to/frontend/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }location /这个try_files配置很重要因为Vue路由如果是history模式刷新某个二级页面时Nginx会去找对应的真实文件找不到就会404try_files把它回退到index.html由前端路由接管页面渲染。Django这边还需要设置DEBUGFalse收集静态文件到指定目录配置ALLOWED_HOSTS为你的域名或IP然后关掉DRF的调试页面。别忘了在WSGI服务那块设置好环境变量我遇到过几次部署完访问500一查是环境变量没加载导致数据库连接配置丢失。5. 常见问题速查表与项目扩展建议5.1 高频报错与对应解决办法现象可能原因解决办法pip install时提示No matching distributionPython版本过新库还没适配换3.10或3.11再试或指定更低版本库python manage.py migrate没有反应忘了把app加入INSTALLED_APPS检查app名称拼写加入后重新migrate前端请求接口报CORS错误跨域配置缺失Vite代理或后端安装django-cors-headers配置白名单POST请求返回403CSRF验证未处理前后端分离项目对API关闭CSRF或改用JWT接口返回500控制台显示KeyError前端传参名字和后端不一致用前后端开发工具同时打开调试对比请求参数名商品列表接口很慢N1查询或全表扫描用select_related优化外键查询数据量大了加索引表格显示[object Object]前端展示字段是对象而不是值后端序列化器里处理成字符串用source属性透出字段登录后刷新页面就退出token没持久化或路由守卫配置错误localstorage存token路由守卫加白名单判断每个问题我都经历过或帮别人排查过。最想重点提醒的还是第一条Python版本不要追新稳定优先。很多朋友装了最新的Python 3.13连pandas、mysqlclient这种基础库都装不上项目就卡在环境这关。凭借多年的项目经验我真的建议生产项目和课程设计都用3.10或3.11踩坑的人太多了。5.2 这个项目还能扩展成什么样第一版跑通后扩展空间其实非常大。根据业务优先级我建议按这个顺序做加法和优化报损报溢模块。超市里生鲜损耗不可避免加一个报损单功能记录损耗商品和数量同时生成库存流水报表里能看到报损金额。这个模块代码量和入库单高度相似实现成本低但业务价值很直观。会员管理模块。会员卡、积分累计、会员价、充值余额这些功能可以单独建一个member的app。设计上是会员表和消费记录表销售下单时关联会员ID接口计算积分或折扣。数据看板大屏。用ECharts或DataV做个可视化大屏展示实时销售额、热销品类、门店客流趋势。这类页面在毕业设计答辩时演示效果极好给评审的“第一印象”加分很多。前端引入ECharts后端要额外提供一个统计汇总接口把昨天、今天、近7天数据对比返回给前端。条形码扫描支持。收银场景下扫描枪本质就是个键盘扫一个条码等于在输入框里快速输入一串数字并回车。前端做好条码输入框的监听扫码后立即查询并加入购物车体验立刻从“手工输入”变成“扫一下就行”这也是收银系统真正落地的关键一步。权限精细化。现在只有管理员和收银员两个角色可以扩展成RBAC模型把菜单权限、按钮权限都放到数据库配置前端根据后端返回的权限列表动态渲染菜单。这个功能偏向中大型系统但如果要拿这个项目去面试提一嘴你能设计RBAC会有很大加分。移动端适配。把销售报表和库存查询做成H5页面让店长在手机上就能看到数据。Vue项目本身可以多写几个路由页面用rem或vw适配手机屏幕。如果不想自己处理适配也可以直接用Vant组件库其他页面代码基本不用动。5.3 给新手和答辩/面试选手的特别建议如果你是拿这个项目去答辩或者面试我给你三个特别建议。第一个建议一定要能讲清楚一个“技术难点”和它的解决方案。比如并发扣库存用事务和行锁这个点就能体现出你的工程思维比罗列“我用了Vue、Django、MySQL”有说服力得多。一定要提前在本地模拟演示这个场景比如开两个页面同时下单同一种库存只有1件的商品其中一个会看到“库存不足”的提示这个效果展示出来非常加分。第二个建议要能说出每一个设计选择的理由。为什么用Django不用Flask为什么金额用Decimal不用Float为什么库存要写流水账而不存一个数字这些问题的答案我在这篇文章里都提到了。面试官问设计方案的时候有条理地回答“我选这个是因为XXX”和“我不选那个是因为XXX”立刻就能和背教程的候选人拉开差距。第三个建议项目要讲真实的使用场景不要套那些“随着互联网的发展”式的套话。直接说这个小超市原来用什么Excel表格记录有什么痛点你这个系统帮他解决了什么问题每个模块是怎么走的流程。把自己代入真实业务答辩或面试时怎么问都不会慌。写在最后的一点体会回到开头那句话超市货品管理系统看起来是个经典CRUD项目但真正把它做扎实你会发现每个模块都藏着不少门道。库存流水让每一件商品的变化都有迹可循事务和行锁让并发销售不乱套Decimal字段让金额计算经得起推敲这些细节比“跑通一个项目”值钱得多。以后你接任何业务系统这些基本功都会反复用到。我建议你拿到这套代码后不要只满足于跑起来试着把入库、销售、报表这条主链路从头到尾走一遍再自己做两个小扩展比如加个“今日毛利”统计或“库存预警”推送你对这套系统的理解就真正变成自己的了。