毕业设计选了零售店铺管理系统这个题目又是一个Django项目。这篇文章我打算换个说法不按论文那种“摘要-需求分析-详细设计”的格式写单纯聊聊这套系统实际开发过程中我是怎么一步步把需求落地成代码的踩过哪些坑哪些代码值得直接抄走哪些设计一开始就该想清楚。这套系统主要包括商品管理、进货入库、销售出库、库存预警、供应商和员工管理以及最基本的销售统计报表前端部分用了Django自带模板加一些轻量JavaScript库后台管理基于Django Admin做了深度定制数据库用的MySQL。如果你也在做类似的Django管理系统或者正准备拿“零售店铺管理信息系统”作为课程设计、毕业设计题目这篇文章应该能帮你省不少时间。下面按我实际开发的顺序来写。1. 需求拆解与数据库建模先把店铺的一天“翻译”成数据表做任何一个管理系统最忌讳的就是拿到题目就写代码。零售店铺看起来业务简单无非是进货、卖货、管库存但真要把一家店的日常运营落到系统里先得把“店铺的一天”完整走一遍才能把实体和关系找全。1.1 从业务流程倒推功能模块我花了半天时间梳理典型零售店铺的业务流程大致如下店员上班查看今日库存供应商送货店员清点后入库顾客购物前台收款并打印小票下班前盘点库存核对销售额。把这个流程对应到系统里至少要拆出以下模块商品管理商品基本信息、分类、条码、进价、售价、库存上下限进货管理供应商档案、进货单、进货明细、入库操作销售管理收银台下单、销售单、销售明细、退货处理库存管理实时库存查询、库存流水、库存预警报表统计销售额统计、热销商品排名、利润统计系统管理员工账号、角色权限这里有个很多初学者容易犯的错直接把“进货单”和“销售单”当成一张表里面放一堆商品字段。正确做法是拆成主表 明细表也就是“单头”和“单行”的结构。因为一张进货单可能包含几十种商品每种商品有自己的数量和进价如果单头明细混在一张表里查询、统计、修改都会非常痛苦。1.2 核心表结构设计我最终设计的核心数据表如下以商品、进货、销售三条链路为主线category商品分类表字段包括名称、父级分类、排序号product商品表与分类表关联包含条码、名称、规格、单位、进价、售价、库存上限、库存下限supplier供应商表包含名称、联系人、电话、地址purchase_order进货单主表包含单号、供应商、进货日期、操作员、总金额、备注purchase_item进货单明细表包含所属进货单、商品、进货价、数量、小计sale_order销售单主表包含单号、收银员、销售日期、总金额、实收金额、找零sale_item销售单明细表包含所属销售单、商品、售价、数量、小计stock_flow库存流水表记录每一次入库、出库、退货、盘点导致的库存变动employee员工表与Django自带User表做一对一关联设计时有一个关键点商品表里不要直接存库存数量。这是很多课程设计项目最喜欢做的事在product表里加一个stock字段每次进货、销售都用update语句直接加减。这样做小项目演示没问题但一旦出现退货、修改历史单据、盘点纠错库存数据就会变得不可追溯。我的做法是通过stock_flow表记录每次变动实时库存用Sum聚合查询算出来再配合商品表里的stock_warning预警逻辑数据可追溯性就强很多。1.3 为什么用MySQL而不是SQLiteDjango自带的SQLite数据库对学习和小规模部署完全够用但我这个项目最终选择MySQL主要考虑两点。一是课程设计或毕业论文需要体现一定的工程深度MySQL在事务处理、并发控制、数据容量上明显更适合零售这种频繁写入的场景二是Django在部署到云服务器时MySQL Gunicorn Nginx是更常见的组合边开发边把坑踩了后面部署更省事。需要注意Django连接MySQL需要安装mysqlclient或pymysql驱动。pymysql纯Python实现安装简单但性能略低mysqlclient是C扩展性能更好。我最后选的是mysqlclient因为Django官方文档推荐的就是它。2. 开发环境搭建与项目初始化版本选型、虚拟环境与数据库连接这个环节看着基础但一套稳定的环境能让你接下来几周少很多麻烦。我把我最终确定的环境和初始化方式列一下。2.1 Python与Django版本选择选版本是个容易纠结的问题我的建议是如果是为了稳定做完一个项目优先选Django 3.2 LTS。这个版本官方支持周期长网上教程最多遇到报错几乎都能搜到解决方案。Django 4.x和5.x虽然新特性多但部分第三方库尤其是老牌报表面板、富文本编辑器可能还不兼容没必要在这个环节给自己制造额外障碍。我的环境是Python 3.10 Django 3.2完全够用。安装Django时我习惯用虚拟环境venv避免全局环境被不同项目的依赖搞乱python3 -m venv venv source venv/bin/activate pip install django3.2 pip install mysqlclient2.2 mysqlclient安装与常见问题安装mysqlclient在Windows和Linux上是两种体验。Linux比较简单先装依赖库再pip install即可sudo apt-get install python3-dev default-libmysqlclient-dev build-essential pip install mysqlclientWindows用户如果没有装对应版本的VC编译工具直接pip install mysqlclient经常会报错。两个替代方案去 这个网站 下载对应的.whl文件手动安装或者改用pymysql然后在项目的__init__.py里加两行代码import pymysql pymysql.install_as_MySQLdb()这个方案最省事尤其是答辩演示环境不固定、需要在几台电脑上快速跑起来的时候。我自己的开发机最后用的就是pymysql部署到Linux服务器时才换成mysqlclient性能和兼容性兼顾。2.3 Django项目与应用结构设计创建项目时我用了startproject和startapp命令但自动生成的目录结构不够清晰我按业务模块重新组织了一下retail_store/ ├── manage.py ├── config/ # 项目配置 │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── product/ # 商品管理 │ ├── purchase/ # 进货管理 │ ├── sale/ # 销售管理 │ ├── report/ # 报表统计 │ └── system/ # 员工权限 ├── static/ ├── templates/ └── requirements.txt把不同业务模块拆成多个app而不是把所有模型塞进一个大models.py里逻辑上更清爽也方便以后单独扩展某个模块。比如我要给商品模块加一个“批量导入Excel”功能直接在apps/product/里加代码就行不影响其他模块。2.4 settings.py关键配置settings.py里有几个配置比较关键。数据库配置我最终是这样写的DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: retail_db, USER: root, PASSWORD: yourpassword, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { init_command: SET sql_modeSTRICT_TRANS_TABLES, } } }需要注意sql_mode设置如果去掉严格模式某些字段长度超限时MySQL会静默截断而不是报错这对于需要保证数据完整性的进销存系统来说风险很大。关于中文显示字符集要在创建数据库时指定为utf8mb4CREATE DATABASE retail_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;否则后面存商品名称、供应商地址时可能出现乱码。这个坑我印象很深当时创建数据库时没指定字符集存中文进去再查出来就变成了一堆问号查了很久才发现是库级别的问题。3. 核心业务模块开发商品、进货、销售与库存联动的完整实现业务代码是整个系统的核心我按模块逐个讲重点说清楚模型字段设计和视图逻辑以及为什么这样写。3.1 商品管理模块商品表是整套系统的地基字段设计直接影响后续的进货、销售、统计。我最终确认为以下字段class Product(models.Model): name models.CharField(max_length128, verbose_name商品名称) barcode models.CharField(max_length64, uniqueTrue, 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(default10, verbose_name库存下限) stock_upper_limit models.IntegerField(default9999, verbose_name库存上限) is_active models.BooleanField(defaultTrue, verbose_name是否启用) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) updated_at models.DateTimeField(auto_nowTrue, verbose_name更新时间) class Meta: db_table product ordering [-id]这里有几个字段设计上的考虑条码字段必须唯一。零售商品按条码扫码是主流方式如果允许重复条码收银时就会扫出好几件商品这是功能性bug。价格用DecimalField而不用FloatField。FloatField存储浮点数在做金额累加、折扣计算时可能产生0.10.2≠0.3的精度问题这在财务环节是绝对不能接受的。DecimalField(max_digits10, decimal_places2)精确到小数点后两位足以覆盖绝大多数零售场景。分类外键用on_deletemodels.PROTECT。如果某个分类下还有商品直接删除分类会导致商品无处归类。PROTECT会让Django在删除时抛出ProtectedError强制你先处理分类下的商品这比CASCADE静默删除安全得多。3.2 进货模块事务与库存联动进货单的保存是一个典型的多表事务操作。用户在前端填一份进货单包含供应商和多种商品点击保存后系统需要同时做三件事创建purchase_order主表记录、创建purchase_item明细记录、同步写入stock_flow库存流水。这个操作必须用事务包裹否则可能出现主表保存成功、明细保存失败导致的数据不一致。Django提供了transaction.atomic()装饰器用法非常清晰from django.db import transaction transaction.atomic def purchase_save(request): # 校验前端传参 supplier_id request.POST.get(supplier_id) items_data json.loads(request.POST.get(items)) # 创建进货单主表 purchase_order PurchaseOrder.objects.create( order_noPO time.strftime(%Y%m%d%H%M%S), supplier_idsupplier_id, total_amountcalculate_total(items_data), operatorrequest.user ) # 创建进货明细并更新库存流水 for item in items_data: PurchaseItem.objects.create( purchase_orderpurchase_order, product_iditem[product_id], purchase_priceDecimal(item[price]), quantityitem[quantity], subtotalDecimal(item[price]) * item[quantity] ) StockFlow.objects.create( product_iditem[product_id], flow_typein, quantityitem[quantity], related_orderpurchase_order )用事务的好处是任何一个环节出错前面的数据库操作全部回滚不会留下“单头有、明细没”的孤儿数据。我测试时专门模拟过明细中某个商品已被下架的情况整个单子直接报错库存不做任何变动数据一致性有了保证。3.3 销售模块库存扣减与防超卖销售收银是使用频率最高的功能对性能和数据一致性要求也最高。我在销售单保存时加了一步库存预检查每次扣减库存前先查询当前库存是否足够from django.db.models import Sum def check_stock(product_id, need_quantity): stock_in StockFlow.objects.filter( product_idproduct_id, flow_typein ).aggregate(totalSum(quantity))[total] or 0 stock_out StockFlow.objects.filter( product_idproduct_id, flow_typeout ).aggregate(totalSum(quantity))[total] or 0 current_stock stock_in - stock_out return current_stock need_quantity这个查询逻辑虽然简单但如果每次销售都实时聚合数据量大时性能会有问题。优化思路是把当前库存冗余到product表里销售时用select_for_update()行锁来防止并发超卖。我演示阶段用的还是聚合查询因为数据量级还远不到性能瓶颈做课程设计的话用这种方式更直观也更容易在论文里解释清楚。3.4 库存预警实现库存预警的逻辑不复杂查询商品当前库存与商品表里的stock_lower_limit比较低于下限就标记为“库存不足”。我在首页加了一个汇总面板展示库存不足商品数量、今日销售额、今日订单数让管理员一打开系统就能看到重点。这个面板是直接用Django模板的{% for %}循环和控制语句渲染的不需要额外的前后端分离结构简单页面直接用模板渲染反而更高效。4. Django Admin深度定制把自带后台改造成好用点的管理界面Django Admin是最容易被小看的模块。很多人以为admin.site.register(Product)就完事了界面丑、操作繁琐、逻辑混乱最后答辩时演示效果很差。我花了不少时间在Admin定制上效果也立竿见影。4.1 ModelAdmin核心配置list_display与list_filter我先定义了一个ProductAdmin把列表页展示哪些字段、哪些字段可搜索、哪些字段可过滤全配好class ProductAdmin(admin.ModelAdmin): list_display (name, barcode, category, purchase_price, sale_price, stock_status) list_filter (category, is_active) search_fields (name, barcode) list_per_page 20 def stock_status(self, obj): stock get_current_stock(obj.id) if stock obj.stock_lower_limit: return 库存不足 return f{stock} stock_status.short_description 当前库存这里有几个比较提升体验的设置list_display里放了自定义方法stock_status可以直接在商品列表看到实时库存和预警状态不用点进详情页list_filter按分类、启用状态过滤商品多的时候特别好用search_fields加上条码和名称扫码枪输入条码能直接定位商品list_per_page控制每页行数商品数据量大的时候分页比一次加载几百行好得多4.2 在Admin里注册联动功能的实现Admin不只是增删改查还可以加自定义按钮。我在进货单详情页加了一个“入库审核”按钮点击后执行事务性的入库操作。这个做法是给ModelAdmin增加一个actions方法def approve_purchase(self, request, queryset): for order in queryset: if order.status pending: with transaction.atomic(): order.status approved order.save() # 生成入库流水 for item in order.purchaseitem_set.all(): StockFlow.objects.create(...) self.message_user(request, 选中进货单已审核入库)这种方式把业务逻辑和后台管理界面整合在一起实际操作人员不需要在Admin之外再开一个页面使用体验比原生的增删改查高一个档次。4.3 第三方界面美化库SimpleUI原生Admin样式偏后台风格色彩单一。做课程设计或毕业设计想视觉效果好一点可以用django-simpleui安装后自动替换Admin界面主题pip install django-simpleui安装后在INSTALLED_APPS里把simpleui放在django.contrib.admin之前重新访问后台就是一套现代化风格界面自带侧边栏、谷歌图标、深色模式基本上零配置。这个方法强烈推荐给想在答辩时让界面好看一点但又不想自己写前端的同学能省大量精力。但有一点要提醒第三方美化库可能会和部分自定义Admin行为冲突。我遇到过一次simpleui的下拉菜单无法正常显示自定义button的问题排查了很久才确认是样式覆盖导致的。如果出现类似问题优先检查一下是否和界面库的CSS冲突或者查阅项目issues不要上来就怀疑自己的业务代码。5. 查询、删除与数据完整性的边界ORM操作里容易忽视的坑Django的ORM上手很快但很多“看似简单”的操作背后有隐藏的坑。尤其是在涉及删除和外键约束的时候处理不好轻则数据错乱重则线上事故。这部分我踩过的坑值得展开聊聊。5.1 删除商品为什么不建议用硬删除很多初学者写的删除逻辑是def product_delete(request, product_id): Product.objects.filter(idproduct_id).delete() return redirect(product_list)这行代码执行后商品记录确实消失了但它关联的进货明细、销售明细还在那些明细里的外键指向一个不存在的商品后续统计报表会出错。更严重的是如果订单表里的外键设置了on_deleteCASCADE删除商品会把历史订单明细一起删掉这等于销毁了营业记录。我的做法是软删除给Product表加一个is_active字段删除操作只是把该字段置为Falsedef product_delete(request, product_id): # 软删除保留历史单据关联仅标记为停用 Product.objects.filter(idproduct_id).update(is_activeFalse) return redirect(product_list)商品列表页查询时默认加上is_activeTrue过滤界面上就等于“删除”了。这样历史销售和进货数据依然能按外键关联查询报表统计不会丢数据而实际系统中商品也不会消失。类似的逻辑也适用于供应商、员工等主数据。原则很简单涉及历史单据的实体一律软删除。只有像草稿状态的进货单这种没有后续关联的数据才允许真正物理删除。5.2 理解Django外键的on_delete选项外键的on_delete是很多初学Django的人忽略但特别重要的字段。Django 2.0以后on_delete是必选参数可选值有CASCADE级联删除删除主表数据时自动删除所有关联数据。适合“订单删除时明细一并删除”的场景PROTECT如果存在关联数据则阻止删除抛出ProtectedError。适合商品分类这种不允许删掉有内容的分类SET_NULL关联数据置为NULL字段前提是该字段设置了nullTrue。适合员工离职后把负责人的外键置空保留订单信息但不再指向某个具体员工SET_DEFAULT删除后赋默认值需要字段本身设置了default值我项目中purchase_item和purchase_order之间的关系用的是CASCADE因为一张进货单没有了它的明细自然也没有存在意义。product对category用的是PROTECTproduct对purchase_item用的是PROTECT防止商品被误删导致历史单据失效。每个选择背后都要有业务逻辑支撑这就是“根据业务设计数据库”的含义。5.3 ORM查询性能和select_related优化商品列表页如果显示每个商品的分类名称、当前库存用ORM查询时容易掉进N1查询陷阱。举个例子products Product.objects.filter(is_activeTrue) for p in products: print(p.category.name) # 每次循环都查一次分类表总共查询了1次商品表N次分类表。商品多的时候性能很差。解决办法是使用select_related让它一次性连表查出来products Product.objects.select_related(category).filter(is_activeTrue)生成的SQL会通过LEFT JOIN把category字段一起查出来放进缓存后续访问p.category.name不再发起SQL查询。select_related适用于一对一、多对一的外键关联如果是多对多或者反向关联要改用prefetch_related。在列表页、首页概览这种需要展示关联字段的场景主动加上这两个方法能明显感觉到页面响应速度的提升。6. 文件输出与响应头细节销售单导出与StreamingHttpResponse实战管理系统除了在线操作往往还需要把数据导出成文件比如销售记录导出CSV财务核对、供货单打印。Django实现文件导出不复杂但有几个细节容易踩坑。6.1 用StreamingHttpResponse实现CSV文件下载普通的HttpResponse是把整个文件内容都加载到内存再返回数据量大的时候内存占用高。StreamingHttpResponse的优势是边生成边传输适合大数据量导出。Django官方文档推荐导出CSV就用它import csv from django.http import StreamingHttpResponse def export_sales_csv(request): result SaleItem.objects.select_related(sale_order, product).all() def generate_csv(): with open(sales_export.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([单号, 商品名称, 售价, 数量, 小计, 销售日期]) for item in result: writer.writerow([ item.sale_order.order_no, item.product.name, item.sale_price, item.quantity, item.subtotal, item.sale_order.sale_date.strftime(%Y-%m-%d %H:%M:%S) ]) response StreamingHttpResponse(generate_csv(), content_typetext/csv) response[Content-Disposition] attachment; filenamesales_export.csv return response这里有两个要点。第一encodingutf-8-sig而不是utf-8是为了让Excel直接打开CSV时中文不乱码。utf-8-sig会在文件开头写入BOM头Excel识别后就能正确解析这是我实际导出后发现乱码后调整的。第二生成方式不是先把全部行装进list再返回而是generate_csv()这个生成器边遍历边写边传大数据量下内存占用很稳定不会有一次性载入几万条记录导致卡死的现象。6.2 Content-Disposition中文文件名编码问题文件名如果是中文直接写filename销售报表.csv浏览器大概率会乱码。正确的做法是使用RFC 5987规定的filename*格式把中文转成UTF-8编码后再用URL编码表示from urllib.parse import quote filename 销售报表.csv response[Content-Disposition] fattachment; filename*UTF-8{quote(filename)}这样下载下来的文件名在Windows、macOS浏览中文都能正常显示。这个小坑很不起眼但每次导出中文文件名时都要踩记住这个格式一劳永逸。6.3 Excel导出用openpyxl动态生成CSV适合数据量大的场景但缺乏样式控制合并单元格等操作也做不了。毕业设计如果要求导出更“美观”的Excel表格可以用openpyxl库动态生成。基本流程是创建工作簿、写入表头、循环写入数据、设置列宽、保存到BytesIO对象最后封装成HttpResponse返回from openpyxl import Workbook from openpyxl.styles import Font, Alignment from io import BytesIO def export_excel(request): wb Workbook() ws wb.active ws.title 销售统计 headers [日期, 销售额, 订单数] ws.append(headers) for row_data in get_sales_statistics(): ws.append(row_data) # 设置表头样式 for cell in ws[1]: cell.font Font(boldTrue) cell.alignment Alignment(horizontalcenter) stream BytesIO() wb.save(stream) response HttpResponse(stream.getvalue(), content_typeapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheet) response[Content-Disposition] fattachment; filename*UTF-8{quote(销售统计.xlsx)} return response这段代码直接抄去用就行核心是把工作簿保存到内存中的BytesIO而不是写入磁盘文件避免临时文件残留。7. 前后端交互与模板渲染登录状态判断、收银台与图表展示这套管理系统的主体是后台操作界面但还是要说下前端部分。零售店铺的收银台需要快速操作响应要好报表页需要直观展示数据趋势。这两块对Django模板开发都很典型。7.1 收银台页面模板渲染少量JavaScript收银台界面我没有用任何前端框架Django模板原生JavaScript足够。核心交互是销售员在输入框扫描条码或输入商品名搜前端发AJAX请求到后端接口查询商品信息拿到后渲染到购物车表格中动态更新总金额。AJAX接口我实现为一个返回JSON的视图from django.http import JsonResponse def get_product_by_barcode(request): barcode request.GET.get(barcode, ) try: product Product.objects.get(barcodebarcode, is_activeTrue) return JsonResponse({ code: 0, data: { id: product.id, name: product.name, sale_price: str(product.sale_price), stock: get_current_stock(product.id) } }) except Product.DoesNotExist: return JsonResponse({code: 1, msg: 商品不存在或已下架})前端拿到商品数据后加入购物车数组同时检查库存是否充足不足则弹提示。整个收银过程不需要刷新页面体验比较顺畅。结账提交时用fetch一次把购物车数据以POST方式发给后端由后端事务创建销售单并扣库存。7.2 登录权限控制登录要求与角色判断店铺管理系统涉及员工操作不能所有页面都是开放访问的。Django内置了登录体系和装饰器加上就能用login_required装饰器要求访问用户必须登录未登录跳转到登录页。后台管理页面的权限Django Admin自带了一套基于权限的管理系统教师账号、店长账号、收银员账号可以创建不同的用户组分配不同的权限。比如普通收银员只能处理销售单据不能修改商品价格这在Admin的Group权限配置里勾选即可实现。扩展一点如果你自己写了非Admin页面的业务视图也可以用permission_required按权限控制。这比在视图里写一堆if not request.user.is_superuser要规范得多。7.3 用ECharts做销售趋势图报表统计是我觉得最能出效果、也是答辩时最能加分的一块。我用ECharts的折线图展示近7天销售趋势柱状图展示热销商品Top10。数据接口返回JSON前端图表库负责渲染fetch(/api/sales_trend/?days7) .then(res res.json()) .then(data { const chart echarts.init(document.getElementById(salesTrendChart)); chart.setOption({ xAxis: { type: category, data: data.dates }, yAxis: { type: value }, series: [{ type: line, data: data.amounts, smooth: true }] }); });后端接口用annotate加Count、Sum聚合操作一天内能轻松搞定。折线图柱状图的组合放在首页面板或专门的统计页整个系统的专业感立刻提升不少。图表页面有一个注意事项Django模板里加载ECharts静态文件建议用{% static echarts/echarts.min.js %}而不是CDN地址。答辩现场如果没网CDN加载不出来图表全空白那是很尴尬的场面。把静态文件下载到本地放到static目录确保断网环境下系统功能完整这是我准备演示前特意做的调整。8. 测试联调与部署经验我建议你留出3天做这件事代码写完后还有两件事特别重要全面测试和部署演示。很多人代码写完直接交结果演示时各种报错分数大打折扣。我总结了一些省时省力的经验。8.1 必测的核心流程清单至少把下面这些主流程完整跑一遍确认无bug再考虑提交新增商品、修改商品、停用商品检查列表是否同步更新进货单保存后实时库存是否增加明细是否正确销售单保存后库存是否扣减退货后是否回补库存低于下限时首页预警是否正确显示登录过期后访问受保护页面是否自动跳转登录页中文文件名导出下载后是否乱码销售趋势图、热销商品图数据是否和实际业务一致每个流程我用手机备忘录做了个表测试时逐项打钩。发现bug就记下来集中修复后再回归测试。这个习惯让我最后演示的时候一次跑通没有那种手忙脚乱的时刻。8.2 常见报错与解决办法问题一Did you install mysqlclient or MySQL-python?解决确认已安装mysqlclient或pymysql并且项目的__init__.py已经声明pymysql.install_as_MySQLdb()。如果是mysqlclient还要确认本机有编译所需的系统依赖。问题二TemplateDoesNotExist at /xxx/解决检查模板文件名和路径是否与视图里render的模板名完全一致。Django在DEBUGFalse情况下模板文件改动还需要重启服务或清理缓存排查时先确认开发环境正确。问题三表单提交后CSRF验证失败解决在模板的form标签内加上{% csrf_token %}手动处理POST请求的视图保持csrf_protect或使用csrf_exempt前先想清楚安全问题。问题四销售单保存后库存没有变化解决检查销售单逻辑里是否调用了库存流水的创建代码常见原因是视图提前return导致后半段没执行或者事务回滚后没做异常处理。问题五导出文件下载后打不开解决多半是HttpResponse里的content_type设置不对。CSV用text/csvxlsx必须用application/vnd.openxmlformats-officedocument.spreadsheetml.sheet。另外确保视图没有在返回前向其他输出流写入内容导致文件头被污染。8.3 部署到Linux服务器的基本顺序课程设计能本地跑通就够了但想加分就可以部署到云服务器上让老师通过浏览器直接访问。Django部署最常见的组合是Nginx Gunicorn MySQL。基本步骤如下服务器安装Python、MySQL、Nginx创建虚拟环境安装项目依赖把项目代码上传到服务器修改settings.py的ALLOWED_HOSTS和数据库配置运行python manage.py migrate生成数据表收集静态文件启动Gunicorngunicorn config.wsgi:application -b 127.0.0.1:8000配置Nginx反向代理/到127.0.0.1:8000/static/到Django静态文件目录我这里不展开写了网上成熟的部署教程一搜一大把。但我强烈建议在答辩前至少提前一天在服务器上完整部署一次因为环境差异导致的报错缺依赖、权限、防火墙通常不是临时能解决的早踩早安稳。9. 论文结构怎么写给答辩加分的几张图这个项目如果对应毕业论文或课程设计报告技术实现内容基本够写了。但论文不是代码的堆砌一定要有逻辑框架。我按自己论文最终的目录顺序列个参考第一章 绪论研究背景、意义、国内外研究现状、论文结构第二章 相关技术介绍Django框架、MySQL数据库、ECharts、Bootstrap第三章 系统需求分析可行性分析、功能需求分析、用例图用StarUML画、数据流图第四章 系统设计总体架构图、功能模块图、数据库ER图、核心表结构说明第五章 系统实现按模块截图核心代码说明第六章 系统测试测试目标、测试用例表、测试结果论文里最加分的素材是图——架构图、数据库ER图、功能模块分层图、用例图。这些图用Visio、StarUML、Navicat导出Navicat可以直接反向生成MySQL的ER图都可以重点是清晰展示系统设计思路。数据库表不用全部列在正文用表格把每张表的关键字段列出来更符合阅读习惯。答辩前对照自己论文画出的系统架构图从头到尾把业务逻辑说一遍。每个模块对应的模型名、视图函数名、模板路径熟记于心。老师提问时能准确说出“这个库存预警逻辑写在哪个视图里、用了什么查询方式”比泛泛而谈加分很多。最后再分享一个个人经验像这类管理系统技术难点不在于代码多复杂而在于需求梳理得是否到位、数据关系设计得是否合理、异常情况考虑得是否周全。代码只是把思路落地的过程。哪怕用到的都是Django最基础的能力只要逻辑清楚、模块完整、步骤合规这个项目就是很有说服力的。如果你开发到中途卡住了回到需求本身想一下“这条数据从哪来、到哪去、异常时怎么兜底”大部分问题都能迎刃而解。
毕业设计选了零售店铺管理系统这个题目又是一个Django项目。这篇文章我打算换个说法不按论文那种“摘要-需求分析-详细设计”的格式写单纯聊聊这套系统实际开发过程中我是怎么一步步把需求落地成代码的踩过哪些坑哪些代码值得直接抄走哪些设计一开始就该想清楚。这套系统主要包括商品管理、进货入库、销售出库、库存预警、供应商和员工管理以及最基本的销售统计报表前端部分用了Django自带模板加一些轻量JavaScript库后台管理基于Django Admin做了深度定制数据库用的MySQL。如果你也在做类似的Django管理系统或者正准备拿“零售店铺管理信息系统”作为课程设计、毕业设计题目这篇文章应该能帮你省不少时间。下面按我实际开发的顺序来写。1. 需求拆解与数据库建模先把店铺的一天“翻译”成数据表做任何一个管理系统最忌讳的就是拿到题目就写代码。零售店铺看起来业务简单无非是进货、卖货、管库存但真要把一家店的日常运营落到系统里先得把“店铺的一天”完整走一遍才能把实体和关系找全。1.1 从业务流程倒推功能模块我花了半天时间梳理典型零售店铺的业务流程大致如下店员上班查看今日库存供应商送货店员清点后入库顾客购物前台收款并打印小票下班前盘点库存核对销售额。把这个流程对应到系统里至少要拆出以下模块商品管理商品基本信息、分类、条码、进价、售价、库存上下限进货管理供应商档案、进货单、进货明细、入库操作销售管理收银台下单、销售单、销售明细、退货处理库存管理实时库存查询、库存流水、库存预警报表统计销售额统计、热销商品排名、利润统计系统管理员工账号、角色权限这里有个很多初学者容易犯的错直接把“进货单”和“销售单”当成一张表里面放一堆商品字段。正确做法是拆成主表 明细表也就是“单头”和“单行”的结构。因为一张进货单可能包含几十种商品每种商品有自己的数量和进价如果单头明细混在一张表里查询、统计、修改都会非常痛苦。1.2 核心表结构设计我最终设计的核心数据表如下以商品、进货、销售三条链路为主线category商品分类表字段包括名称、父级分类、排序号product商品表与分类表关联包含条码、名称、规格、单位、进价、售价、库存上限、库存下限supplier供应商表包含名称、联系人、电话、地址purchase_order进货单主表包含单号、供应商、进货日期、操作员、总金额、备注purchase_item进货单明细表包含所属进货单、商品、进货价、数量、小计sale_order销售单主表包含单号、收银员、销售日期、总金额、实收金额、找零sale_item销售单明细表包含所属销售单、商品、售价、数量、小计stock_flow库存流水表记录每一次入库、出库、退货、盘点导致的库存变动employee员工表与Django自带User表做一对一关联设计时有一个关键点商品表里不要直接存库存数量。这是很多课程设计项目最喜欢做的事在product表里加一个stock字段每次进货、销售都用update语句直接加减。这样做小项目演示没问题但一旦出现退货、修改历史单据、盘点纠错库存数据就会变得不可追溯。我的做法是通过stock_flow表记录每次变动实时库存用Sum聚合查询算出来再配合商品表里的stock_warning预警逻辑数据可追溯性就强很多。1.3 为什么用MySQL而不是SQLiteDjango自带的SQLite数据库对学习和小规模部署完全够用但我这个项目最终选择MySQL主要考虑两点。一是课程设计或毕业论文需要体现一定的工程深度MySQL在事务处理、并发控制、数据容量上明显更适合零售这种频繁写入的场景二是Django在部署到云服务器时MySQL Gunicorn Nginx是更常见的组合边开发边把坑踩了后面部署更省事。需要注意Django连接MySQL需要安装mysqlclient或pymysql驱动。pymysql纯Python实现安装简单但性能略低mysqlclient是C扩展性能更好。我最后选的是mysqlclient因为Django官方文档推荐的就是它。2. 开发环境搭建与项目初始化版本选型、虚拟环境与数据库连接这个环节看着基础但一套稳定的环境能让你接下来几周少很多麻烦。我把我最终确定的环境和初始化方式列一下。2.1 Python与Django版本选择选版本是个容易纠结的问题我的建议是如果是为了稳定做完一个项目优先选Django 3.2 LTS。这个版本官方支持周期长网上教程最多遇到报错几乎都能搜到解决方案。Django 4.x和5.x虽然新特性多但部分第三方库尤其是老牌报表面板、富文本编辑器可能还不兼容没必要在这个环节给自己制造额外障碍。我的环境是Python 3.10 Django 3.2完全够用。安装Django时我习惯用虚拟环境venv避免全局环境被不同项目的依赖搞乱python3 -m venv venv source venv/bin/activate pip install django3.2 pip install mysqlclient2.2 mysqlclient安装与常见问题安装mysqlclient在Windows和Linux上是两种体验。Linux比较简单先装依赖库再pip install即可sudo apt-get install python3-dev default-libmysqlclient-dev build-essential pip install mysqlclientWindows用户如果没有装对应版本的VC编译工具直接pip install mysqlclient经常会报错。两个替代方案去 这个网站 下载对应的.whl文件手动安装或者改用pymysql然后在项目的__init__.py里加两行代码import pymysql pymysql.install_as_MySQLdb()这个方案最省事尤其是答辩演示环境不固定、需要在几台电脑上快速跑起来的时候。我自己的开发机最后用的就是pymysql部署到Linux服务器时才换成mysqlclient性能和兼容性兼顾。2.3 Django项目与应用结构设计创建项目时我用了startproject和startapp命令但自动生成的目录结构不够清晰我按业务模块重新组织了一下retail_store/ ├── manage.py ├── config/ # 项目配置 │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── product/ # 商品管理 │ ├── purchase/ # 进货管理 │ ├── sale/ # 销售管理 │ ├── report/ # 报表统计 │ └── system/ # 员工权限 ├── static/ ├── templates/ └── requirements.txt把不同业务模块拆成多个app而不是把所有模型塞进一个大models.py里逻辑上更清爽也方便以后单独扩展某个模块。比如我要给商品模块加一个“批量导入Excel”功能直接在apps/product/里加代码就行不影响其他模块。2.4 settings.py关键配置settings.py里有几个配置比较关键。数据库配置我最终是这样写的DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: retail_db, USER: root, PASSWORD: yourpassword, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { init_command: SET sql_modeSTRICT_TRANS_TABLES, } } }需要注意sql_mode设置如果去掉严格模式某些字段长度超限时MySQL会静默截断而不是报错这对于需要保证数据完整性的进销存系统来说风险很大。关于中文显示字符集要在创建数据库时指定为utf8mb4CREATE DATABASE retail_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;否则后面存商品名称、供应商地址时可能出现乱码。这个坑我印象很深当时创建数据库时没指定字符集存中文进去再查出来就变成了一堆问号查了很久才发现是库级别的问题。3. 核心业务模块开发商品、进货、销售与库存联动的完整实现业务代码是整个系统的核心我按模块逐个讲重点说清楚模型字段设计和视图逻辑以及为什么这样写。3.1 商品管理模块商品表是整套系统的地基字段设计直接影响后续的进货、销售、统计。我最终确认为以下字段class Product(models.Model): name models.CharField(max_length128, verbose_name商品名称) barcode models.CharField(max_length64, uniqueTrue, 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(default10, verbose_name库存下限) stock_upper_limit models.IntegerField(default9999, verbose_name库存上限) is_active models.BooleanField(defaultTrue, verbose_name是否启用) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) updated_at models.DateTimeField(auto_nowTrue, verbose_name更新时间) class Meta: db_table product ordering [-id]这里有几个字段设计上的考虑条码字段必须唯一。零售商品按条码扫码是主流方式如果允许重复条码收银时就会扫出好几件商品这是功能性bug。价格用DecimalField而不用FloatField。FloatField存储浮点数在做金额累加、折扣计算时可能产生0.10.2≠0.3的精度问题这在财务环节是绝对不能接受的。DecimalField(max_digits10, decimal_places2)精确到小数点后两位足以覆盖绝大多数零售场景。分类外键用on_deletemodels.PROTECT。如果某个分类下还有商品直接删除分类会导致商品无处归类。PROTECT会让Django在删除时抛出ProtectedError强制你先处理分类下的商品这比CASCADE静默删除安全得多。3.2 进货模块事务与库存联动进货单的保存是一个典型的多表事务操作。用户在前端填一份进货单包含供应商和多种商品点击保存后系统需要同时做三件事创建purchase_order主表记录、创建purchase_item明细记录、同步写入stock_flow库存流水。这个操作必须用事务包裹否则可能出现主表保存成功、明细保存失败导致的数据不一致。Django提供了transaction.atomic()装饰器用法非常清晰from django.db import transaction transaction.atomic def purchase_save(request): # 校验前端传参 supplier_id request.POST.get(supplier_id) items_data json.loads(request.POST.get(items)) # 创建进货单主表 purchase_order PurchaseOrder.objects.create( order_noPO time.strftime(%Y%m%d%H%M%S), supplier_idsupplier_id, total_amountcalculate_total(items_data), operatorrequest.user ) # 创建进货明细并更新库存流水 for item in items_data: PurchaseItem.objects.create( purchase_orderpurchase_order, product_iditem[product_id], purchase_priceDecimal(item[price]), quantityitem[quantity], subtotalDecimal(item[price]) * item[quantity] ) StockFlow.objects.create( product_iditem[product_id], flow_typein, quantityitem[quantity], related_orderpurchase_order )用事务的好处是任何一个环节出错前面的数据库操作全部回滚不会留下“单头有、明细没”的孤儿数据。我测试时专门模拟过明细中某个商品已被下架的情况整个单子直接报错库存不做任何变动数据一致性有了保证。3.3 销售模块库存扣减与防超卖销售收银是使用频率最高的功能对性能和数据一致性要求也最高。我在销售单保存时加了一步库存预检查每次扣减库存前先查询当前库存是否足够from django.db.models import Sum def check_stock(product_id, need_quantity): stock_in StockFlow.objects.filter( product_idproduct_id, flow_typein ).aggregate(totalSum(quantity))[total] or 0 stock_out StockFlow.objects.filter( product_idproduct_id, flow_typeout ).aggregate(totalSum(quantity))[total] or 0 current_stock stock_in - stock_out return current_stock need_quantity这个查询逻辑虽然简单但如果每次销售都实时聚合数据量大时性能会有问题。优化思路是把当前库存冗余到product表里销售时用select_for_update()行锁来防止并发超卖。我演示阶段用的还是聚合查询因为数据量级还远不到性能瓶颈做课程设计的话用这种方式更直观也更容易在论文里解释清楚。3.4 库存预警实现库存预警的逻辑不复杂查询商品当前库存与商品表里的stock_lower_limit比较低于下限就标记为“库存不足”。我在首页加了一个汇总面板展示库存不足商品数量、今日销售额、今日订单数让管理员一打开系统就能看到重点。这个面板是直接用Django模板的{% for %}循环和控制语句渲染的不需要额外的前后端分离结构简单页面直接用模板渲染反而更高效。4. Django Admin深度定制把自带后台改造成好用点的管理界面Django Admin是最容易被小看的模块。很多人以为admin.site.register(Product)就完事了界面丑、操作繁琐、逻辑混乱最后答辩时演示效果很差。我花了不少时间在Admin定制上效果也立竿见影。4.1 ModelAdmin核心配置list_display与list_filter我先定义了一个ProductAdmin把列表页展示哪些字段、哪些字段可搜索、哪些字段可过滤全配好class ProductAdmin(admin.ModelAdmin): list_display (name, barcode, category, purchase_price, sale_price, stock_status) list_filter (category, is_active) search_fields (name, barcode) list_per_page 20 def stock_status(self, obj): stock get_current_stock(obj.id) if stock obj.stock_lower_limit: return 库存不足 return f{stock} stock_status.short_description 当前库存这里有几个比较提升体验的设置list_display里放了自定义方法stock_status可以直接在商品列表看到实时库存和预警状态不用点进详情页list_filter按分类、启用状态过滤商品多的时候特别好用search_fields加上条码和名称扫码枪输入条码能直接定位商品list_per_page控制每页行数商品数据量大的时候分页比一次加载几百行好得多4.2 在Admin里注册联动功能的实现Admin不只是增删改查还可以加自定义按钮。我在进货单详情页加了一个“入库审核”按钮点击后执行事务性的入库操作。这个做法是给ModelAdmin增加一个actions方法def approve_purchase(self, request, queryset): for order in queryset: if order.status pending: with transaction.atomic(): order.status approved order.save() # 生成入库流水 for item in order.purchaseitem_set.all(): StockFlow.objects.create(...) self.message_user(request, 选中进货单已审核入库)这种方式把业务逻辑和后台管理界面整合在一起实际操作人员不需要在Admin之外再开一个页面使用体验比原生的增删改查高一个档次。4.3 第三方界面美化库SimpleUI原生Admin样式偏后台风格色彩单一。做课程设计或毕业设计想视觉效果好一点可以用django-simpleui安装后自动替换Admin界面主题pip install django-simpleui安装后在INSTALLED_APPS里把simpleui放在django.contrib.admin之前重新访问后台就是一套现代化风格界面自带侧边栏、谷歌图标、深色模式基本上零配置。这个方法强烈推荐给想在答辩时让界面好看一点但又不想自己写前端的同学能省大量精力。但有一点要提醒第三方美化库可能会和部分自定义Admin行为冲突。我遇到过一次simpleui的下拉菜单无法正常显示自定义button的问题排查了很久才确认是样式覆盖导致的。如果出现类似问题优先检查一下是否和界面库的CSS冲突或者查阅项目issues不要上来就怀疑自己的业务代码。5. 查询、删除与数据完整性的边界ORM操作里容易忽视的坑Django的ORM上手很快但很多“看似简单”的操作背后有隐藏的坑。尤其是在涉及删除和外键约束的时候处理不好轻则数据错乱重则线上事故。这部分我踩过的坑值得展开聊聊。5.1 删除商品为什么不建议用硬删除很多初学者写的删除逻辑是def product_delete(request, product_id): Product.objects.filter(idproduct_id).delete() return redirect(product_list)这行代码执行后商品记录确实消失了但它关联的进货明细、销售明细还在那些明细里的外键指向一个不存在的商品后续统计报表会出错。更严重的是如果订单表里的外键设置了on_deleteCASCADE删除商品会把历史订单明细一起删掉这等于销毁了营业记录。我的做法是软删除给Product表加一个is_active字段删除操作只是把该字段置为Falsedef product_delete(request, product_id): # 软删除保留历史单据关联仅标记为停用 Product.objects.filter(idproduct_id).update(is_activeFalse) return redirect(product_list)商品列表页查询时默认加上is_activeTrue过滤界面上就等于“删除”了。这样历史销售和进货数据依然能按外键关联查询报表统计不会丢数据而实际系统中商品也不会消失。类似的逻辑也适用于供应商、员工等主数据。原则很简单涉及历史单据的实体一律软删除。只有像草稿状态的进货单这种没有后续关联的数据才允许真正物理删除。5.2 理解Django外键的on_delete选项外键的on_delete是很多初学Django的人忽略但特别重要的字段。Django 2.0以后on_delete是必选参数可选值有CASCADE级联删除删除主表数据时自动删除所有关联数据。适合“订单删除时明细一并删除”的场景PROTECT如果存在关联数据则阻止删除抛出ProtectedError。适合商品分类这种不允许删掉有内容的分类SET_NULL关联数据置为NULL字段前提是该字段设置了nullTrue。适合员工离职后把负责人的外键置空保留订单信息但不再指向某个具体员工SET_DEFAULT删除后赋默认值需要字段本身设置了default值我项目中purchase_item和purchase_order之间的关系用的是CASCADE因为一张进货单没有了它的明细自然也没有存在意义。product对category用的是PROTECTproduct对purchase_item用的是PROTECT防止商品被误删导致历史单据失效。每个选择背后都要有业务逻辑支撑这就是“根据业务设计数据库”的含义。5.3 ORM查询性能和select_related优化商品列表页如果显示每个商品的分类名称、当前库存用ORM查询时容易掉进N1查询陷阱。举个例子products Product.objects.filter(is_activeTrue) for p in products: print(p.category.name) # 每次循环都查一次分类表总共查询了1次商品表N次分类表。商品多的时候性能很差。解决办法是使用select_related让它一次性连表查出来products Product.objects.select_related(category).filter(is_activeTrue)生成的SQL会通过LEFT JOIN把category字段一起查出来放进缓存后续访问p.category.name不再发起SQL查询。select_related适用于一对一、多对一的外键关联如果是多对多或者反向关联要改用prefetch_related。在列表页、首页概览这种需要展示关联字段的场景主动加上这两个方法能明显感觉到页面响应速度的提升。6. 文件输出与响应头细节销售单导出与StreamingHttpResponse实战管理系统除了在线操作往往还需要把数据导出成文件比如销售记录导出CSV财务核对、供货单打印。Django实现文件导出不复杂但有几个细节容易踩坑。6.1 用StreamingHttpResponse实现CSV文件下载普通的HttpResponse是把整个文件内容都加载到内存再返回数据量大的时候内存占用高。StreamingHttpResponse的优势是边生成边传输适合大数据量导出。Django官方文档推荐导出CSV就用它import csv from django.http import StreamingHttpResponse def export_sales_csv(request): result SaleItem.objects.select_related(sale_order, product).all() def generate_csv(): with open(sales_export.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([单号, 商品名称, 售价, 数量, 小计, 销售日期]) for item in result: writer.writerow([ item.sale_order.order_no, item.product.name, item.sale_price, item.quantity, item.subtotal, item.sale_order.sale_date.strftime(%Y-%m-%d %H:%M:%S) ]) response StreamingHttpResponse(generate_csv(), content_typetext/csv) response[Content-Disposition] attachment; filenamesales_export.csv return response这里有两个要点。第一encodingutf-8-sig而不是utf-8是为了让Excel直接打开CSV时中文不乱码。utf-8-sig会在文件开头写入BOM头Excel识别后就能正确解析这是我实际导出后发现乱码后调整的。第二生成方式不是先把全部行装进list再返回而是generate_csv()这个生成器边遍历边写边传大数据量下内存占用很稳定不会有一次性载入几万条记录导致卡死的现象。6.2 Content-Disposition中文文件名编码问题文件名如果是中文直接写filename销售报表.csv浏览器大概率会乱码。正确的做法是使用RFC 5987规定的filename*格式把中文转成UTF-8编码后再用URL编码表示from urllib.parse import quote filename 销售报表.csv response[Content-Disposition] fattachment; filename*UTF-8{quote(filename)}这样下载下来的文件名在Windows、macOS浏览中文都能正常显示。这个小坑很不起眼但每次导出中文文件名时都要踩记住这个格式一劳永逸。6.3 Excel导出用openpyxl动态生成CSV适合数据量大的场景但缺乏样式控制合并单元格等操作也做不了。毕业设计如果要求导出更“美观”的Excel表格可以用openpyxl库动态生成。基本流程是创建工作簿、写入表头、循环写入数据、设置列宽、保存到BytesIO对象最后封装成HttpResponse返回from openpyxl import Workbook from openpyxl.styles import Font, Alignment from io import BytesIO def export_excel(request): wb Workbook() ws wb.active ws.title 销售统计 headers [日期, 销售额, 订单数] ws.append(headers) for row_data in get_sales_statistics(): ws.append(row_data) # 设置表头样式 for cell in ws[1]: cell.font Font(boldTrue) cell.alignment Alignment(horizontalcenter) stream BytesIO() wb.save(stream) response HttpResponse(stream.getvalue(), content_typeapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheet) response[Content-Disposition] fattachment; filename*UTF-8{quote(销售统计.xlsx)} return response这段代码直接抄去用就行核心是把工作簿保存到内存中的BytesIO而不是写入磁盘文件避免临时文件残留。7. 前后端交互与模板渲染登录状态判断、收银台与图表展示这套管理系统的主体是后台操作界面但还是要说下前端部分。零售店铺的收银台需要快速操作响应要好报表页需要直观展示数据趋势。这两块对Django模板开发都很典型。7.1 收银台页面模板渲染少量JavaScript收银台界面我没有用任何前端框架Django模板原生JavaScript足够。核心交互是销售员在输入框扫描条码或输入商品名搜前端发AJAX请求到后端接口查询商品信息拿到后渲染到购物车表格中动态更新总金额。AJAX接口我实现为一个返回JSON的视图from django.http import JsonResponse def get_product_by_barcode(request): barcode request.GET.get(barcode, ) try: product Product.objects.get(barcodebarcode, is_activeTrue) return JsonResponse({ code: 0, data: { id: product.id, name: product.name, sale_price: str(product.sale_price), stock: get_current_stock(product.id) } }) except Product.DoesNotExist: return JsonResponse({code: 1, msg: 商品不存在或已下架})前端拿到商品数据后加入购物车数组同时检查库存是否充足不足则弹提示。整个收银过程不需要刷新页面体验比较顺畅。结账提交时用fetch一次把购物车数据以POST方式发给后端由后端事务创建销售单并扣库存。7.2 登录权限控制登录要求与角色判断店铺管理系统涉及员工操作不能所有页面都是开放访问的。Django内置了登录体系和装饰器加上就能用login_required装饰器要求访问用户必须登录未登录跳转到登录页。后台管理页面的权限Django Admin自带了一套基于权限的管理系统教师账号、店长账号、收银员账号可以创建不同的用户组分配不同的权限。比如普通收银员只能处理销售单据不能修改商品价格这在Admin的Group权限配置里勾选即可实现。扩展一点如果你自己写了非Admin页面的业务视图也可以用permission_required按权限控制。这比在视图里写一堆if not request.user.is_superuser要规范得多。7.3 用ECharts做销售趋势图报表统计是我觉得最能出效果、也是答辩时最能加分的一块。我用ECharts的折线图展示近7天销售趋势柱状图展示热销商品Top10。数据接口返回JSON前端图表库负责渲染fetch(/api/sales_trend/?days7) .then(res res.json()) .then(data { const chart echarts.init(document.getElementById(salesTrendChart)); chart.setOption({ xAxis: { type: category, data: data.dates }, yAxis: { type: value }, series: [{ type: line, data: data.amounts, smooth: true }] }); });后端接口用annotate加Count、Sum聚合操作一天内能轻松搞定。折线图柱状图的组合放在首页面板或专门的统计页整个系统的专业感立刻提升不少。图表页面有一个注意事项Django模板里加载ECharts静态文件建议用{% static echarts/echarts.min.js %}而不是CDN地址。答辩现场如果没网CDN加载不出来图表全空白那是很尴尬的场面。把静态文件下载到本地放到static目录确保断网环境下系统功能完整这是我准备演示前特意做的调整。8. 测试联调与部署经验我建议你留出3天做这件事代码写完后还有两件事特别重要全面测试和部署演示。很多人代码写完直接交结果演示时各种报错分数大打折扣。我总结了一些省时省力的经验。8.1 必测的核心流程清单至少把下面这些主流程完整跑一遍确认无bug再考虑提交新增商品、修改商品、停用商品检查列表是否同步更新进货单保存后实时库存是否增加明细是否正确销售单保存后库存是否扣减退货后是否回补库存低于下限时首页预警是否正确显示登录过期后访问受保护页面是否自动跳转登录页中文文件名导出下载后是否乱码销售趋势图、热销商品图数据是否和实际业务一致每个流程我用手机备忘录做了个表测试时逐项打钩。发现bug就记下来集中修复后再回归测试。这个习惯让我最后演示的时候一次跑通没有那种手忙脚乱的时刻。8.2 常见报错与解决办法问题一Did you install mysqlclient or MySQL-python?解决确认已安装mysqlclient或pymysql并且项目的__init__.py已经声明pymysql.install_as_MySQLdb()。如果是mysqlclient还要确认本机有编译所需的系统依赖。问题二TemplateDoesNotExist at /xxx/解决检查模板文件名和路径是否与视图里render的模板名完全一致。Django在DEBUGFalse情况下模板文件改动还需要重启服务或清理缓存排查时先确认开发环境正确。问题三表单提交后CSRF验证失败解决在模板的form标签内加上{% csrf_token %}手动处理POST请求的视图保持csrf_protect或使用csrf_exempt前先想清楚安全问题。问题四销售单保存后库存没有变化解决检查销售单逻辑里是否调用了库存流水的创建代码常见原因是视图提前return导致后半段没执行或者事务回滚后没做异常处理。问题五导出文件下载后打不开解决多半是HttpResponse里的content_type设置不对。CSV用text/csvxlsx必须用application/vnd.openxmlformats-officedocument.spreadsheetml.sheet。另外确保视图没有在返回前向其他输出流写入内容导致文件头被污染。8.3 部署到Linux服务器的基本顺序课程设计能本地跑通就够了但想加分就可以部署到云服务器上让老师通过浏览器直接访问。Django部署最常见的组合是Nginx Gunicorn MySQL。基本步骤如下服务器安装Python、MySQL、Nginx创建虚拟环境安装项目依赖把项目代码上传到服务器修改settings.py的ALLOWED_HOSTS和数据库配置运行python manage.py migrate生成数据表收集静态文件启动Gunicorngunicorn config.wsgi:application -b 127.0.0.1:8000配置Nginx反向代理/到127.0.0.1:8000/static/到Django静态文件目录我这里不展开写了网上成熟的部署教程一搜一大把。但我强烈建议在答辩前至少提前一天在服务器上完整部署一次因为环境差异导致的报错缺依赖、权限、防火墙通常不是临时能解决的早踩早安稳。9. 论文结构怎么写给答辩加分的几张图这个项目如果对应毕业论文或课程设计报告技术实现内容基本够写了。但论文不是代码的堆砌一定要有逻辑框架。我按自己论文最终的目录顺序列个参考第一章 绪论研究背景、意义、国内外研究现状、论文结构第二章 相关技术介绍Django框架、MySQL数据库、ECharts、Bootstrap第三章 系统需求分析可行性分析、功能需求分析、用例图用StarUML画、数据流图第四章 系统设计总体架构图、功能模块图、数据库ER图、核心表结构说明第五章 系统实现按模块截图核心代码说明第六章 系统测试测试目标、测试用例表、测试结果论文里最加分的素材是图——架构图、数据库ER图、功能模块分层图、用例图。这些图用Visio、StarUML、Navicat导出Navicat可以直接反向生成MySQL的ER图都可以重点是清晰展示系统设计思路。数据库表不用全部列在正文用表格把每张表的关键字段列出来更符合阅读习惯。答辩前对照自己论文画出的系统架构图从头到尾把业务逻辑说一遍。每个模块对应的模型名、视图函数名、模板路径熟记于心。老师提问时能准确说出“这个库存预警逻辑写在哪个视图里、用了什么查询方式”比泛泛而谈加分很多。最后再分享一个个人经验像这类管理系统技术难点不在于代码多复杂而在于需求梳理得是否到位、数据关系设计得是否合理、异常情况考虑得是否周全。代码只是把思路落地的过程。哪怕用到的都是Django最基础的能力只要逻辑清楚、模块完整、步骤合规这个项目就是很有说服力的。如果你开发到中途卡住了回到需求本身想一下“这条数据从哪来、到哪去、异常时怎么兜底”大部分问题都能迎刃而解。
