1. 选题逻辑为什么是Django ERP 小程序这个组合先说结论这个选题几乎是为课程设计和毕业设计量身定做的标准答案。每年都有大量学生卡在选题这一步要么选了个纯算法题最后做不出界面要么选了个管理系统但技术栈太老没亮点答辩时被老师追问得哑口无言。而Django ERP 微信小程序这个组合恰好把三个最容易被答辩老师认可的元素都占了。第一ERP企业资源计划属于典型的业务复杂度足够但不至于失控的选题方向。它天然包含基础资料管理用户、部门、客户、供应商、进销存采购、入库、出库、库存、订单审批、数据统计报表等模块每个模块之间都有数据关联这就能体现你的数据库设计能力。做管理系统最怕的是增删改查四件套写完之后没有东西可写而ERP的业务链条很长从采购到入库到销售形成一个闭环写文档的时候每个模块都能展开几百字这对凑够论文篇幅非常友好。第二Django作为Python系最成熟的重量级Web框架自带Admin后台、ORM、Migrate机制、认证系统这些内置能力能帮你节省大量重复造轮子的时间。更关键的是一旦你写出本系统基于Django MTV架构模式采用类视图Class-Based View实现业务逻辑配合ORM完成多表关联查询答辩老师就知道你确实系统学过这门课而不是靠复制粘贴拼出来的。第三小程序端的存在让这套系统从纯PC端管理系统升级成了多端协同办公平台这在选题创新性上是一个显著的加分点。现在的企业办公趋势本来就是移动化领导在外面出差需要审批采购单销售在外面跑客户需要查库存仓库管理员拿着手机就能扫码盘点——小程序端解决的正是这些真实场景里的碎片化办公需求。而且微信小程序不用装App、用完即走、开放了扫码API开发门槛比安卓原生低得多学生两周左右就能把前端页面调通。这个选题适合谁坦白说基础中等偏下的学生做这个题反而比基础好的学生做算法题更稳妥。原因很简单ERP系统的每一个模块单独拿出来都不难难的是把多个模块串起来、把数据表之间的外键关系理清楚。而课程设计/毕业设计答辩的核心考察点恰恰是你的系统能不能完整跑起来你对业务的理解有没有逻辑闭环这两件事黛Jango都能帮你兜底。2. 系统整体架构与数据库设计思路2.1 MTV架构下的前后端分离实践在真正动手写代码之前先想清楚架构问题。很多人一听到Django就以为必须用模板渲染页面其实课程设计阶段完全可以用更现代的前后端分离模式——Django只负责输出JSON数据接口小程序端负责渲染页面Web管理端可以继续用Django模板也可以做成APIVue的形态。我的建议是采用混合架构PC后台管理端用Django模板渲染理由见下面第3节小程序端通过RESTful API与后端通信API层用django-rest-framework实现。这样做的实际好处有三个小程序端和后端可以并行开发你负责定义好API接口文档后小程序部分可以同时开工对于期末赶工来说效率翻倍。答辩演示时你可以掏出手机现场扫码展示Web端审核→小程序端收到推送→库存同步更新这样的跨端闭环演示效果拉满。如果指导老师临时要求加一个App端或者加一个数据大屏你不需要推倒重来直接复用小程序的API层改造成本极低。实际项目中的请求流转是这样的小程序端发起HTTP请求 → Django URL路由层把请求交给对应视图 → 视图通过ORM操作MySQL数据库 → 序列化器把结果转成JSON → 返回给小程序渲染页面。整个过程你可以理解为前端只负责长得好看后端只负责数据不出错。2.2 数据库表设计从业务梳理到ER图落地ERP系统的数据库设计是整个项目的地基。地基打歪了后面每写一个功能都会发现表关系对不上改来改去把自己绕晕。我见过太多人一上来就建表做到采购模块的时候发现采购单、采购明细、商品、供应商关联关系理不清最后只能把所有字段拼在一张大表里答辩时被老师一戳就破。正确的顺序是先画业务流程。一个最小可用的企业ERP办公系统至少需要覆盖以下闭环采购单采购员发起→主管审批→入库→ 库存变动入库单/出库单→ 销售出库销售员创建订单→扣减库存→ 报表统计。围绕这个流程核心数据表至少有11张模块数据表核心字段说明用户权限auth_userDjango内置用户表扩展profile字段存职位、部门用户权限department部门表id, name, manager_id用户权限role角色表超级管理员、采购员、审批员、销售员基础资料customer客户表公司名、联系人、电话、信用额度基础资料supplier供应商表名称、联系人、账期、供货品类基础资料product商品表编码、名称、规格、单位、成本价、零售价采购管理purchase_order采购单主表单号、供应商id、审批状态、总金额采购管理purchase_order_item采购明细表采购单id、商品id、数量、单价库存管理inventory库存表商品id、仓库id、当前数量、预警阈值库存管理stock_transaction出入库流水表商品id、类型、数量、关联单据号销售管理sales_order销售订单表客户id、商品明细、金额、发货状态表和表之间的外键关系建议遵循两个原则。第一主表与明细表必须分离就像采购单和采购明细如果合成一张表一条采购单含三种商品就要存三行整体数据库会变得非常冗余。第二库存变动必须走流水表而不是直接改库存表同时用事务保证数据一致性。举个例子销售下单时扣减库存如果直接inventory.stock - 1发生退货时数据就乱了而通过stock_transaction记录每一笔变动库存表的值始终等于流水表累加的结果账目才是清晰的。代码层面可以这样处理from django.db import transaction transaction.atomic def create_sales_order(request): # 1. 创建销售订单主表和明细 # 2. 校验库存是否充足 # 3. 写入库存流水表出库类型 # 4. 更新商品表的库存字段关于数据库选型课程设计阶段直接选MySQL即可不要为了秀操作选PostgreSQL或MongoDB。原因很现实你答辩时老师大概率会问为什么选这个数据库MySQL你可以理直气壮地回答企业级应用的主流选择生态完善、团队熟悉度最高、与Django ORM兼容性好。另外MySQL可视化工具用Navicat或者DataGrip都可以我用DataGrip多一些因为它的ER图自动生成功能可以直接帮你把表关系画出来放进论文里当插图非常专业。2.3 Django应用拆分每个App只干一件事Django的一个核心实践是每个App只负责一个业务域。以本系统为例建议这样拆分src/ ├── erp_project/ # 项目配置目录settings.py, urls.py ├── apps/ │ ├── users/ # 用户、角色、部门、权限 │ ├── base/ # 商品、客户、供应商基础资料 │ ├── purchase/ # 采购单、采购入库 │ ├── inventory/ # 库存、出入库流水、预警 │ ├── sales/ # 销售订单、发货管理 │ └── reports/ # 统计报表这样拆的好处显而易见每个App的model.py、views.py、admin.py各司其职代码总量可能差不多但可读性和维护性完全不在一个量级。答辩时如果老师问你这个系统扩展性怎么样你可以顺势说如果需要增加生产管理模块只需要新增一个production App通过外键关联到产品表和库存表不触碰已有代码——这就是架构层面的加分回答。3. 权限设计与核心业务模块实现3.1 三种角色权限从ORM到视图层的完整链路一个小型ERP系统我认为把权限角色收敛到三种就够了系统管理员管人管权限管所有数据、部门主管审批采购单、查看所有报表、普通员工采购员只能操作自己的单据销售员只能看自己的客户和订单。不要一上来就做RBAC基于角色的访问控制全套光是权限表和角色表的关系映射就能消耗你两周时间而且答辩时老师不会因为你权限做得重给你加分只会因为你业务闭环没跑通而扣分。当然Django自带的Group和Permission机制可以直接利用。具体做法是在usersApp中创建三个Group然后在视图层通过自定义装饰器做权限校验。这里给大家一个非常实用的装饰器写法from django.core.exceptions import PermissionDenied def role_required(allowed_roles): def decorator(view_func): def _wrapped_view(request, *args, **kwargs): if not request.user.is_authenticated: return redirect(/admin/login/) user_groups request.user.groups.values_list(name, flatTrue) if not set(user_groups) set(allowed_roles): raise PermissionDenied return view_func(request, *args, **kwargs) return _wrapped_view return decorator # 使用示例 role_required([采购员, 部门主管, 系统管理员]) def purchase_order_list(request): orders PurchaseOrder.objects.filter(creatorrequest.user) return render(request, purchase/order_list.html, {orders: orders})权限设计里有一个常见的坑前端隐藏按钮不等于后端安全。很多学生在页面模板里用{% if user.role xxx %}控制按钮是否可见却忘了接口层面的权限校验结果用Postman直接POST请求就能越权操作。记住一条铁律所有权限判断都必须在后端视图层做前端隐藏只是体验优化真正的安全闸门在后端。3.2 采购、库存、销售三大核心业务模块的实现要点采购模块的核心逻辑是单证分离。采购员创建采购单 → 提交审批 → 主管在后台审批通过 → 触发入库操作 → 生成库存流水。技术上有一个较难处理的点采购明细表通常是动态增删行的用户在页面上可能加了五条明细又删掉两条所以前端必须用动态表单JS渲染行数据收集数据后端接收JSON列表后逐一写入明细表。这个场景非常适合用django-rest-framework的Serializer来处理class PurchaseOrderItemSerializer(serializers.ModelSerializer): product_id serializers.IntegerField() class Meta: model PurchaseOrderItem fields [product_id, quantity, unit_price] class PurchaseOrderSerializer(serializers.ModelSerializer): items PurchaseOrderItemSerializer(manyTrue) class Meta: model PurchaseOrder fields [supplier, expected_date, items, remark] def create(self, validated_data): items_data validated_data.pop(items) order PurchaseOrder.objects.create(**validated_data) for item in items_data: PurchaseOrderItem.objects.create(orderorder, **item) return order库存模块最需要重视的是并发问题。这个点也是我在搜索热词列表里看到erp库存场景高并发的解决方案被高频搜索的原因。用Django ORM处理并发扣库存最忌讳的写法是product Product.objects.get(id1) if product.stock 5: product.stock - 5 product.save()这就是典型的读取-修改-写入竞态条件。两个请求同时读到stock10都判断够扣5件各自扣完写回变成5实际应该扣10件变成0。正解的方案是用原子更新F表达式一次性完成判断扣减from django.db.models import F updated Product.objects.filter(id1, stock__gte5).update(stockF(stock) - 5) if updated 0: return JsonResponse({code: 1, msg: 库存不足})filter(stock__gte5)是在数据库层面做条件判断update是原子操作两个动作在一条SQL里完成不会出现并发下的中间状态。这一手写出来答辩时你可以主动提一句这里我处理了高并发场景下的超卖问题老师的眼神会明显不一样。销售模块相对简单核心是订单状态机设计。一个销售订单至少要经历待付款 → 已付款 → 已发货 → 已完成 / 已取消 这几个状态。强烈建议用Django的IntegerField配合choices定义状态而不是存字符串class SalesOrder(models.Model): STATUS_CHOICES ( (1, 待付款), (2, 已付款), (3, 已发货), (4, 已完成), (5, 已取消), ) status models.IntegerField(choicesSTATUS_CHOICES, default1)用整型做状态的好处是第一前端wx:switch或者下拉框映射数字更省流量第二排序性能好第三各种审批流的节点判断直接if order.status 3就能过滤逻辑写起来非常丝滑。3.3 Django Admin后台学生项目最容易做出企业感的地方这里要重点强烈推荐一件事不要只把Django Admin当作给自己调试的草稿箱把它当作系统管理员端来认真设计。原因在于你实际没有时间开发一个完整的PC后台管理端但Admin自带的列表筛选、搜索、权限分配、数据导出能力恰好满足ERP中后台管理的基本需求。实现的姿势有两个细节值得做。第一自定义Admin类通过list_display控制显示列通过list_filter控制筛选器admin.register(PurchaseOrder) class PurchaseOrderAdmin(admin.ModelAdmin): list_display [order_no, supplier, status, total_amount, creator, created_at] list_filter [status, supplier] search_fields [order_no, supplier__name] list_per_page 20 autocomplete_fields [supplier]第二做审批动作的下拉框让主管在Admin后台直接操作审批流。自定义Admin Action是Django被低估的技能admin.action(description批量通过审批) def approve_orders(modeladmin, request, queryset): for order in queryset: if order.status 1: order.status 2 order.approver request.user order.approved_at timezone.now() order.save() class PurchaseOrderAdmin(admin.ModelAdmin): actions [approve_orders]这样设计之后你的系统PC管理端就白嫖了Django Admin的安全认证、Crud操作、审计日志你只需要把精力全部投入到业务逻辑和小程序端开发上。答辩时展示走一遍流程登录Admin后台 → 筛选出待审批订单 → 下拉批量通过 → 库存自动增加 → 演示完毕。一气呵成。4. 小程序端设计与前后端联调4.1 小程序端页面架构站在手机办公场景做减法小程序端的设计原则和PC端完全不同。在电脑上用户可以在十几个页面之间跳转手机上多跳一步用户就烦了。所以小程序端需要克制只保留移动办公最高频的三个场景首页办公台待办事宜、库存预警、快捷入口、审批工作台主管审批采购单、库存查询扫码或搜索查库存、做入库/出库操作。页面结构建议pages/ ├── index/ # 首页欢迎语、待办事项、快捷功能 ├── purchase/list/ # 我的采购单列表 ├── purchase/create/ # 新建采购单支持动态添加商品行 ├── approval/list/ # 待我审批的列表 ├── approval/detail/ # 审批详情含通过/驳回按钮 ├── inventory/query/ # 库存查询支持扫码 ├── inventory/shelve/ # 入库操作 └── mine/ # 个人中心登录信息、部门、角色页面数量控制在这个量级是合理的每个页面一个WXMLJSWXSSJSON文件总计约32个前端文件再加上公共组件总代码量对课程设计来说是工作量充足但不至于熬夜的水平。4.2 微信登录与Django的Token认证对接小程序端登录是前后端联调的第一个关键点。微信小程序的登录流程是小程序端调用wx.login()→ 拿到临时code → 把code发给后端 → 后端通过code向微信服务器换取openid → 后端用openid关联本地用户 → 给小程序签发token。在Django端我们用djangorestframework-simplejwt来实现Token机制核心步骤只需要三步第一步在settings.py中注册JWT认证REST_FRAMEWORK { DEFAULT_AUTHENTICATION_CLASSES: ( rest_framework_simplejwt.authentication.JWTAuthentication, ), }第二步提供微信登录接口接收code后调用微信接口换取openiddef wx_login(request): code request.data.get(code) # 调用微信jscode2session接口返回openid和session_key resp requests.get( https://api.weixin.qq.com/sns/jscode2session, params{appid: APP_ID, secret: APP_SECRET, js_code: code, grant_type: authorization_code} ).json() openid resp.get(openid) user, created User.objects.get_or_create(usernameopenid) refresh RefreshToken.for_user(user) return JsonResponse({access: str(refresh.access_token), refresh: str(refresh)})第三步小程序端每次请求在Header里带Authorization: Bearer tokenDjango端JWT中间件自动校验。这里有一个值得注意的细节伪造的AccessToken无法冒充正常用户但前端如果存储了Token一定要存在wx.setStorageSync而不是放在全局变量里。全局变量在App启动后可能被释放而且部分机型会层出现页面刷新后Token丢失的问题用wx.setStorageSync(token, token)持久化后每次启动先从Storage里取回。4.3 列表渲染与表单提交的两个经典坑小程序端写采购单创建页面最容易踩的两个坑值得提前说。坑一动态表单的索引错乱。用户在页面上添加商品行你会用一个data数组存储所有行数据用wx:for渲染。如果你用>submitOrder() { const items this.data.items.map((item, index) ({ product_id: item.productId, quantity: parseInt(item.quantity), unit_price: parseFloat(item.price), })); // 将items通过wx.request POST到后端 }坑二WXML里的数据绑定不支持复杂方法调用。页面上想显示采购单总金额不要在WXML里写{{ item.price * item.quantity }}这种表达式WXML的能力有限写复杂了会出诡异渲染问题。正确做法是在JS的data中维护一个totalAmount字段每次增删行或修改单价/数量时重新计算并setData。虽然多几行代码但数据流清晰调试时出了Bug也容易定位。4.4 WebSocket消息推送让待审批主动找上门热词里的django websocket实现后台有数据前端推送恰好对应ERP系统里一个非常真实的需求销售员在手机上提交了采购申请主管不会一直在审批页刷新怎么让主管第一时间知道你有一条待审批单子答案是WebSocket长连接推送。Django做WebSocket有几个方案最原生的是channels官方推荐的异步WebSocket框架也有极简方案是用dwebsocket不过课程设计阶段我推荐先用channels把链路跑通因为答辩时你能准确地描述出ASGI服务器 Channel Layer 前端WebSocket的完整链路。后端核心代码# consumers.py import json from channels.generic.websocket import WebsocketConsumer class ApprovalConsumer(WebsocketConsumer): def connect(self): # 将当前连接加入审批推送组 self.group_name approval_notify async_to_sync(self.channel_layer.group_add)(self.group_name, self.channel_name) self.accept() def receive(self, text_data): # 收到前端消息后可做一些处理 pass def approval_message(self, event): # 从channel layer收到审批消息后推给前端 self.send(text_datajson.dumps({ type: approval, order_no: event[order_no], title: 您有一条新的采购单待审批, })) # 在创建采购单的视图中审批后触发推送 from channels.layers import get_channel_layer channel_layer get_channel_layer() async_to_sync(channel_layer.group_send)( approval_notify, {type: approval_message, order_no: order.order_no} )前端小程序端用wx.connectSocket建立长连接收到消息后利用wx.vibrateShort()振动提醒主管同时弹窗显示您有一条编号为PO202408001的采购单待审批。这个功能的演示效果在答辩时堪称杀手锏——两台设备一台提交一台振动提醒全场目光都会被你吸引。需要注意的是WebSocket在课程设计阶段不要想做得太复杂能推一条审批通知就够了实时库存同步、实时聊天这些完全可以作为后期扩展方向写进文档。5. 万字论文写作框架与答辩准备5.1 论文结构的黄金比例关于万字文档这个卖点我给一个可以直接套用的文档框架总共约1万到1.2万字分为6章第1章 绪论约1200字企业信息化背景、ERP系统的国内外研究现状、本课题的研究意义。这一章难度最低、字数最好凑把企业数字化转型移动办公业务流程自动化这些关键词铺开写即可。第2章 相关技术介绍约1500字Django框架的MTV模式、MySQL的存储引擎、微信小程序开发框架、JWT认证机制、WebSocket长连接协议。每个技术写250字左右注意不要写成纯概念搬运最好加一句在本系统中的具体作用。第3章 系统分析约1500字可行性分析技术/经济/操作、需求分析功能需求非功能需求、用例图。这里要把用例图画全画出采购员、销售员、主管、管理员四个角色各自的用例。第4章 系统设计约2500字总体架构图、功能模块设计、数据库设计这部分建议写到1500-2000字是所有章节中分数占比最高的。每个表的字段名、类型、约束以表格形式呈现表之间的ER图单独放一整页。第5章 系统实现约2500字按照用户权限模块→基础资料→采购→库存→销售→小程序端→消息推送的顺序每个模块讲清楚实现逻辑核心代码片段运行界面截图。每个模块配1-2个代码块和一张截图字数自然就到位了。第6章 系统测试与总结约1300字测试计划、测试用例表功能测试性能测试兼容性测试、测试结论、项目总结与展望。注意文档中最容易被老师挑刺的是测试部分。很多同学只写经过测试系统功能正常这样等于告诉老师你没做过测试。正确的做法是做一张完整的测试用例表测试编号测试模块测试步骤预期结果实际结果结论T001用户登录输入正确账号密码登录成功成功通过T002越权访问普通员工访问审批接口拒绝访问返回403通过T003并发扣库存两个请求同时扣减同一商品库存5件扣减两次共10件扣减10件通过T004采购单审批主管审批通过采购单库存自动增加库存增加通过5.2 答辩前必须能随手画出的三张图答辩的核心不是念PPT而是在老师的追问下能画出系统骨架图。我强烈建议你在答辩前练熟下面三张图的画法不需要美观A4纸上用几分钟就能画出来第一张是系统架构图最上层是PC管理端和小程序端中间是Django业务层按App拆分的六个模块下层是MySQL数据库旁边标注JWT认证WebSocket推送两条横向链路。第二张是业务流程图以采购业务为主线画出一个环状流程——采购员创建采购单 → 主管审批 → 采购单状态改变 → 触发入库 → 库存表更新 → 流水表记录 → 首页报表刷新。第三张是数据库ER图把11张核心数据表的主外键关系画一遍不要求特别精确但要让老师看到你脑子里的数据流是通的。答辩时最忌讳照着PPT逐行念。如果老师问你为什么在这个地方用事务你就直接把第2节那段transaction.atomic的代码写出来告诉他因为采购入库涉及主表明细表库存表三处写入任何一个失败都会导致数据不一致所以必须保证原子性。这种回答方式比背一百个概念都有说服力。5.3 交付物整理源码、数据库、文档的目录规范线上交付时建议把整个项目整理成清晰的目录结构一是方便答辩演示时快速进入代码讲解二是给评审老师一个软件工程规范的第一印象ERP_Office_System/ ├── src/ # 源代码根目录 │ ├── erp_project/ # Django项目配置目录 │ ├── apps/ # 六个业务应用 │ ├── templates/ # PC端页面模板 │ ├── static/ # 静态资源css/js/图片 │ └── requirements.txt # Python依赖清单django, djangorestframework, etc. ├── wechat_mini/ # 微信小程序源码目录 ├── database/ │ ├── erp_office.sql # 数据库导出脚本 │ └── erp_office.sqlite3 # 本地调试用的SQLite副本可选 ├── docs/ │ ├── 开题报告.docx │ ├── 项目说明书.docx │ └── 答辩PPT.pptx └── README.md # 项目说明与部署启动步骤关于数据库文件要注意一个细节如果答辩机器上没有MySQL环境提供一个SQLite副本和一个MySQL导出脚本保证任何环境都能在两分钟内跑起来。README里写清楚三步启动命令pip install -r requirements.txt python manage.py migrate python manage.py runserver 0.0.0.0:8000再加上一句admin账号admin / admin123评审老师想自己动手体验时就能直接登录这要省去大量口头解释的时间。6. 开发流程中的低效陷阱与真实经验6.1 边写边改的进度黑洞与如何破局课程设计最容易翻车的不是写不出来而是写到一半推翻重来。我见过至少五个同学是在做完基础资料模块之后发现采购入库的流程设计不合理又Open数据库把表的外键关系改了结果所有已经写完的查询代码全部报错。所以务必在动手写代码之前把这个检查清单过一遍用户角色到底有几种每种角色能看到哪些页面采购入库之后库存是扣了再入库还是入库即加库存销售订单的取消是否要回填库存审批不通过时采购单是允许修改重新提交还是直接作废所有价格字段用的是DecimalField还是FloatField务必用Decimal浮点计算会出精度问题这些问题在文档第3章系统分析阶段就应该全部定稿。我的习惯是先用Excel列一张功能模块×角色×操作的权限矩阵表把每个单元格的可见/可操作/不可见填完再开始建表写代码。看起来多花了几个小时实际省掉的是后面几十个小时的返工时间。6.2 前后端联调时改一处崩三处的典型场景当我开发小程序端时曾遇到一个非常经典的问题小程序端接收到后端返回的采购单明细JSON是items: [{product_id: 1, quantity: 5}]但页面需要用product_name来显示商品名称。如果后端序列化时没有把商品名称带上前端就要根据product_id再发一个详情请求来查名称这样多一次来回不说还会出现数据加载顺序问题。最优解是后端在类型化接口中做关联查询嵌套序列化。写一个ProductSerializer嵌套到PurchaseOrderItemSerializerclass ProductBriefSerializer(serializers.ModelSerializer): class Meta: model Product fields [id, name, spec] class PurchaseOrderItemSerializer(serializers.ModelSerializer): product ProductBriefSerializer(read_onlyTrue) class Meta: model PurchaseOrderItem fields [product, quantity, unit_price]这样小程序端一次请求就能拿到商品名称和规格。当初我在这个问题上多花了一整天原因是图省事直接在Product模型里加了__str__方法然后序列化字段直接写product返回模型的字符串表示前端拿到的是商品名规格这种拼接文本还要自己正则切分非常痛苦。所以你写API时一定要想清楚前端真正需要哪些字段然后让后端一次性给全。6.3 答辩演示时的环境准备清单最后讲讲答辩演示这个容易忽略的环节。再多说一句演示环境请提前一天在答辩教室的机器上完整跑通一遍。我亲身经历过同学因为笔记本HDMI接口在教室的投影仪上没反应被迫用手机拍电脑屏幕演示的尴尬场面。演示前建议准备这些电脑充满电备用HDMI转接头和网线转接头都带上。MySQL服务设为开机自启而且不要设密码或把密码写到README里免得现场手忙脚乱输错。浏览器的书签栏预存好三个URLhttp://127.0.0.1:8000/admin/、http://127.0.0.1:8000/purchase/、一个测试采购单详情页。手机连接与电脑同一WiFi提前测试小程序API请求的域名白名单。本地调试时记得在微信开发者工具中勾选不校验合法域名。准备一份3分钟演示脚本顺序建议是用户登录 → 展示Admin后台数据列表 → 演示创建采购单 → 切换到手机小程序端演示审批 → 回到电脑端展示库存变化 → 打开报表页面展示统计图表。答辩现场演示用的数据库建议用一套种子数据把每个列表页都填满至少30条商品、10个客户、5个供应商这样列表页的翻页功能和统计报表的图表都不会是空白期。不要空库演示空列表页面看起来很low而且让老师觉得你的系统没有实际数据验证过。从技术选型到论文写作再到最后的答辩演示这套Django ERP 微信小程序的组合方案按部就班执行下来是能够在两周左右完整交付的。整个过程踩过的坑我都尽量写出来了照着走能帮你绕开大部分不必要的弯路。最后预祝你课程设计顺利答辩一次通过。 Django+ERP+微信小程序：课程设计/毕业设计实战指南
1. 选题逻辑为什么是Django ERP 小程序这个组合先说结论这个选题几乎是为课程设计和毕业设计量身定做的标准答案。每年都有大量学生卡在选题这一步要么选了个纯算法题最后做不出界面要么选了个管理系统但技术栈太老没亮点答辩时被老师追问得哑口无言。而Django ERP 微信小程序这个组合恰好把三个最容易被答辩老师认可的元素都占了。第一ERP企业资源计划属于典型的业务复杂度足够但不至于失控的选题方向。它天然包含基础资料管理用户、部门、客户、供应商、进销存采购、入库、出库、库存、订单审批、数据统计报表等模块每个模块之间都有数据关联这就能体现你的数据库设计能力。做管理系统最怕的是增删改查四件套写完之后没有东西可写而ERP的业务链条很长从采购到入库到销售形成一个闭环写文档的时候每个模块都能展开几百字这对凑够论文篇幅非常友好。第二Django作为Python系最成熟的重量级Web框架自带Admin后台、ORM、Migrate机制、认证系统这些内置能力能帮你节省大量重复造轮子的时间。更关键的是一旦你写出本系统基于Django MTV架构模式采用类视图Class-Based View实现业务逻辑配合ORM完成多表关联查询答辩老师就知道你确实系统学过这门课而不是靠复制粘贴拼出来的。第三小程序端的存在让这套系统从纯PC端管理系统升级成了多端协同办公平台这在选题创新性上是一个显著的加分点。现在的企业办公趋势本来就是移动化领导在外面出差需要审批采购单销售在外面跑客户需要查库存仓库管理员拿着手机就能扫码盘点——小程序端解决的正是这些真实场景里的碎片化办公需求。而且微信小程序不用装App、用完即走、开放了扫码API开发门槛比安卓原生低得多学生两周左右就能把前端页面调通。这个选题适合谁坦白说基础中等偏下的学生做这个题反而比基础好的学生做算法题更稳妥。原因很简单ERP系统的每一个模块单独拿出来都不难难的是把多个模块串起来、把数据表之间的外键关系理清楚。而课程设计/毕业设计答辩的核心考察点恰恰是你的系统能不能完整跑起来你对业务的理解有没有逻辑闭环这两件事黛Jango都能帮你兜底。2. 系统整体架构与数据库设计思路2.1 MTV架构下的前后端分离实践在真正动手写代码之前先想清楚架构问题。很多人一听到Django就以为必须用模板渲染页面其实课程设计阶段完全可以用更现代的前后端分离模式——Django只负责输出JSON数据接口小程序端负责渲染页面Web管理端可以继续用Django模板也可以做成APIVue的形态。我的建议是采用混合架构PC后台管理端用Django模板渲染理由见下面第3节小程序端通过RESTful API与后端通信API层用django-rest-framework实现。这样做的实际好处有三个小程序端和后端可以并行开发你负责定义好API接口文档后小程序部分可以同时开工对于期末赶工来说效率翻倍。答辩演示时你可以掏出手机现场扫码展示Web端审核→小程序端收到推送→库存同步更新这样的跨端闭环演示效果拉满。如果指导老师临时要求加一个App端或者加一个数据大屏你不需要推倒重来直接复用小程序的API层改造成本极低。实际项目中的请求流转是这样的小程序端发起HTTP请求 → Django URL路由层把请求交给对应视图 → 视图通过ORM操作MySQL数据库 → 序列化器把结果转成JSON → 返回给小程序渲染页面。整个过程你可以理解为前端只负责长得好看后端只负责数据不出错。2.2 数据库表设计从业务梳理到ER图落地ERP系统的数据库设计是整个项目的地基。地基打歪了后面每写一个功能都会发现表关系对不上改来改去把自己绕晕。我见过太多人一上来就建表做到采购模块的时候发现采购单、采购明细、商品、供应商关联关系理不清最后只能把所有字段拼在一张大表里答辩时被老师一戳就破。正确的顺序是先画业务流程。一个最小可用的企业ERP办公系统至少需要覆盖以下闭环采购单采购员发起→主管审批→入库→ 库存变动入库单/出库单→ 销售出库销售员创建订单→扣减库存→ 报表统计。围绕这个流程核心数据表至少有11张模块数据表核心字段说明用户权限auth_userDjango内置用户表扩展profile字段存职位、部门用户权限department部门表id, name, manager_id用户权限role角色表超级管理员、采购员、审批员、销售员基础资料customer客户表公司名、联系人、电话、信用额度基础资料supplier供应商表名称、联系人、账期、供货品类基础资料product商品表编码、名称、规格、单位、成本价、零售价采购管理purchase_order采购单主表单号、供应商id、审批状态、总金额采购管理purchase_order_item采购明细表采购单id、商品id、数量、单价库存管理inventory库存表商品id、仓库id、当前数量、预警阈值库存管理stock_transaction出入库流水表商品id、类型、数量、关联单据号销售管理sales_order销售订单表客户id、商品明细、金额、发货状态表和表之间的外键关系建议遵循两个原则。第一主表与明细表必须分离就像采购单和采购明细如果合成一张表一条采购单含三种商品就要存三行整体数据库会变得非常冗余。第二库存变动必须走流水表而不是直接改库存表同时用事务保证数据一致性。举个例子销售下单时扣减库存如果直接inventory.stock - 1发生退货时数据就乱了而通过stock_transaction记录每一笔变动库存表的值始终等于流水表累加的结果账目才是清晰的。代码层面可以这样处理from django.db import transaction transaction.atomic def create_sales_order(request): # 1. 创建销售订单主表和明细 # 2. 校验库存是否充足 # 3. 写入库存流水表出库类型 # 4. 更新商品表的库存字段关于数据库选型课程设计阶段直接选MySQL即可不要为了秀操作选PostgreSQL或MongoDB。原因很现实你答辩时老师大概率会问为什么选这个数据库MySQL你可以理直气壮地回答企业级应用的主流选择生态完善、团队熟悉度最高、与Django ORM兼容性好。另外MySQL可视化工具用Navicat或者DataGrip都可以我用DataGrip多一些因为它的ER图自动生成功能可以直接帮你把表关系画出来放进论文里当插图非常专业。2.3 Django应用拆分每个App只干一件事Django的一个核心实践是每个App只负责一个业务域。以本系统为例建议这样拆分src/ ├── erp_project/ # 项目配置目录settings.py, urls.py ├── apps/ │ ├── users/ # 用户、角色、部门、权限 │ ├── base/ # 商品、客户、供应商基础资料 │ ├── purchase/ # 采购单、采购入库 │ ├── inventory/ # 库存、出入库流水、预警 │ ├── sales/ # 销售订单、发货管理 │ └── reports/ # 统计报表这样拆的好处显而易见每个App的model.py、views.py、admin.py各司其职代码总量可能差不多但可读性和维护性完全不在一个量级。答辩时如果老师问你这个系统扩展性怎么样你可以顺势说如果需要增加生产管理模块只需要新增一个production App通过外键关联到产品表和库存表不触碰已有代码——这就是架构层面的加分回答。3. 权限设计与核心业务模块实现3.1 三种角色权限从ORM到视图层的完整链路一个小型ERP系统我认为把权限角色收敛到三种就够了系统管理员管人管权限管所有数据、部门主管审批采购单、查看所有报表、普通员工采购员只能操作自己的单据销售员只能看自己的客户和订单。不要一上来就做RBAC基于角色的访问控制全套光是权限表和角色表的关系映射就能消耗你两周时间而且答辩时老师不会因为你权限做得重给你加分只会因为你业务闭环没跑通而扣分。当然Django自带的Group和Permission机制可以直接利用。具体做法是在usersApp中创建三个Group然后在视图层通过自定义装饰器做权限校验。这里给大家一个非常实用的装饰器写法from django.core.exceptions import PermissionDenied def role_required(allowed_roles): def decorator(view_func): def _wrapped_view(request, *args, **kwargs): if not request.user.is_authenticated: return redirect(/admin/login/) user_groups request.user.groups.values_list(name, flatTrue) if not set(user_groups) set(allowed_roles): raise PermissionDenied return view_func(request, *args, **kwargs) return _wrapped_view return decorator # 使用示例 role_required([采购员, 部门主管, 系统管理员]) def purchase_order_list(request): orders PurchaseOrder.objects.filter(creatorrequest.user) return render(request, purchase/order_list.html, {orders: orders})权限设计里有一个常见的坑前端隐藏按钮不等于后端安全。很多学生在页面模板里用{% if user.role xxx %}控制按钮是否可见却忘了接口层面的权限校验结果用Postman直接POST请求就能越权操作。记住一条铁律所有权限判断都必须在后端视图层做前端隐藏只是体验优化真正的安全闸门在后端。3.2 采购、库存、销售三大核心业务模块的实现要点采购模块的核心逻辑是单证分离。采购员创建采购单 → 提交审批 → 主管在后台审批通过 → 触发入库操作 → 生成库存流水。技术上有一个较难处理的点采购明细表通常是动态增删行的用户在页面上可能加了五条明细又删掉两条所以前端必须用动态表单JS渲染行数据收集数据后端接收JSON列表后逐一写入明细表。这个场景非常适合用django-rest-framework的Serializer来处理class PurchaseOrderItemSerializer(serializers.ModelSerializer): product_id serializers.IntegerField() class Meta: model PurchaseOrderItem fields [product_id, quantity, unit_price] class PurchaseOrderSerializer(serializers.ModelSerializer): items PurchaseOrderItemSerializer(manyTrue) class Meta: model PurchaseOrder fields [supplier, expected_date, items, remark] def create(self, validated_data): items_data validated_data.pop(items) order PurchaseOrder.objects.create(**validated_data) for item in items_data: PurchaseOrderItem.objects.create(orderorder, **item) return order库存模块最需要重视的是并发问题。这个点也是我在搜索热词列表里看到erp库存场景高并发的解决方案被高频搜索的原因。用Django ORM处理并发扣库存最忌讳的写法是product Product.objects.get(id1) if product.stock 5: product.stock - 5 product.save()这就是典型的读取-修改-写入竞态条件。两个请求同时读到stock10都判断够扣5件各自扣完写回变成5实际应该扣10件变成0。正解的方案是用原子更新F表达式一次性完成判断扣减from django.db.models import F updated Product.objects.filter(id1, stock__gte5).update(stockF(stock) - 5) if updated 0: return JsonResponse({code: 1, msg: 库存不足})filter(stock__gte5)是在数据库层面做条件判断update是原子操作两个动作在一条SQL里完成不会出现并发下的中间状态。这一手写出来答辩时你可以主动提一句这里我处理了高并发场景下的超卖问题老师的眼神会明显不一样。销售模块相对简单核心是订单状态机设计。一个销售订单至少要经历待付款 → 已付款 → 已发货 → 已完成 / 已取消 这几个状态。强烈建议用Django的IntegerField配合choices定义状态而不是存字符串class SalesOrder(models.Model): STATUS_CHOICES ( (1, 待付款), (2, 已付款), (3, 已发货), (4, 已完成), (5, 已取消), ) status models.IntegerField(choicesSTATUS_CHOICES, default1)用整型做状态的好处是第一前端wx:switch或者下拉框映射数字更省流量第二排序性能好第三各种审批流的节点判断直接if order.status 3就能过滤逻辑写起来非常丝滑。3.3 Django Admin后台学生项目最容易做出企业感的地方这里要重点强烈推荐一件事不要只把Django Admin当作给自己调试的草稿箱把它当作系统管理员端来认真设计。原因在于你实际没有时间开发一个完整的PC后台管理端但Admin自带的列表筛选、搜索、权限分配、数据导出能力恰好满足ERP中后台管理的基本需求。实现的姿势有两个细节值得做。第一自定义Admin类通过list_display控制显示列通过list_filter控制筛选器admin.register(PurchaseOrder) class PurchaseOrderAdmin(admin.ModelAdmin): list_display [order_no, supplier, status, total_amount, creator, created_at] list_filter [status, supplier] search_fields [order_no, supplier__name] list_per_page 20 autocomplete_fields [supplier]第二做审批动作的下拉框让主管在Admin后台直接操作审批流。自定义Admin Action是Django被低估的技能admin.action(description批量通过审批) def approve_orders(modeladmin, request, queryset): for order in queryset: if order.status 1: order.status 2 order.approver request.user order.approved_at timezone.now() order.save() class PurchaseOrderAdmin(admin.ModelAdmin): actions [approve_orders]这样设计之后你的系统PC管理端就白嫖了Django Admin的安全认证、Crud操作、审计日志你只需要把精力全部投入到业务逻辑和小程序端开发上。答辩时展示走一遍流程登录Admin后台 → 筛选出待审批订单 → 下拉批量通过 → 库存自动增加 → 演示完毕。一气呵成。4. 小程序端设计与前后端联调4.1 小程序端页面架构站在手机办公场景做减法小程序端的设计原则和PC端完全不同。在电脑上用户可以在十几个页面之间跳转手机上多跳一步用户就烦了。所以小程序端需要克制只保留移动办公最高频的三个场景首页办公台待办事宜、库存预警、快捷入口、审批工作台主管审批采购单、库存查询扫码或搜索查库存、做入库/出库操作。页面结构建议pages/ ├── index/ # 首页欢迎语、待办事项、快捷功能 ├── purchase/list/ # 我的采购单列表 ├── purchase/create/ # 新建采购单支持动态添加商品行 ├── approval/list/ # 待我审批的列表 ├── approval/detail/ # 审批详情含通过/驳回按钮 ├── inventory/query/ # 库存查询支持扫码 ├── inventory/shelve/ # 入库操作 └── mine/ # 个人中心登录信息、部门、角色页面数量控制在这个量级是合理的每个页面一个WXMLJSWXSSJSON文件总计约32个前端文件再加上公共组件总代码量对课程设计来说是工作量充足但不至于熬夜的水平。4.2 微信登录与Django的Token认证对接小程序端登录是前后端联调的第一个关键点。微信小程序的登录流程是小程序端调用wx.login()→ 拿到临时code → 把code发给后端 → 后端通过code向微信服务器换取openid → 后端用openid关联本地用户 → 给小程序签发token。在Django端我们用djangorestframework-simplejwt来实现Token机制核心步骤只需要三步第一步在settings.py中注册JWT认证REST_FRAMEWORK { DEFAULT_AUTHENTICATION_CLASSES: ( rest_framework_simplejwt.authentication.JWTAuthentication, ), }第二步提供微信登录接口接收code后调用微信接口换取openiddef wx_login(request): code request.data.get(code) # 调用微信jscode2session接口返回openid和session_key resp requests.get( https://api.weixin.qq.com/sns/jscode2session, params{appid: APP_ID, secret: APP_SECRET, js_code: code, grant_type: authorization_code} ).json() openid resp.get(openid) user, created User.objects.get_or_create(usernameopenid) refresh RefreshToken.for_user(user) return JsonResponse({access: str(refresh.access_token), refresh: str(refresh)})第三步小程序端每次请求在Header里带Authorization: Bearer tokenDjango端JWT中间件自动校验。这里有一个值得注意的细节伪造的AccessToken无法冒充正常用户但前端如果存储了Token一定要存在wx.setStorageSync而不是放在全局变量里。全局变量在App启动后可能被释放而且部分机型会层出现页面刷新后Token丢失的问题用wx.setStorageSync(token, token)持久化后每次启动先从Storage里取回。4.3 列表渲染与表单提交的两个经典坑小程序端写采购单创建页面最容易踩的两个坑值得提前说。坑一动态表单的索引错乱。用户在页面上添加商品行你会用一个data数组存储所有行数据用wx:for渲染。如果你用>submitOrder() { const items this.data.items.map((item, index) ({ product_id: item.productId, quantity: parseInt(item.quantity), unit_price: parseFloat(item.price), })); // 将items通过wx.request POST到后端 }坑二WXML里的数据绑定不支持复杂方法调用。页面上想显示采购单总金额不要在WXML里写{{ item.price * item.quantity }}这种表达式WXML的能力有限写复杂了会出诡异渲染问题。正确做法是在JS的data中维护一个totalAmount字段每次增删行或修改单价/数量时重新计算并setData。虽然多几行代码但数据流清晰调试时出了Bug也容易定位。4.4 WebSocket消息推送让待审批主动找上门热词里的django websocket实现后台有数据前端推送恰好对应ERP系统里一个非常真实的需求销售员在手机上提交了采购申请主管不会一直在审批页刷新怎么让主管第一时间知道你有一条待审批单子答案是WebSocket长连接推送。Django做WebSocket有几个方案最原生的是channels官方推荐的异步WebSocket框架也有极简方案是用dwebsocket不过课程设计阶段我推荐先用channels把链路跑通因为答辩时你能准确地描述出ASGI服务器 Channel Layer 前端WebSocket的完整链路。后端核心代码# consumers.py import json from channels.generic.websocket import WebsocketConsumer class ApprovalConsumer(WebsocketConsumer): def connect(self): # 将当前连接加入审批推送组 self.group_name approval_notify async_to_sync(self.channel_layer.group_add)(self.group_name, self.channel_name) self.accept() def receive(self, text_data): # 收到前端消息后可做一些处理 pass def approval_message(self, event): # 从channel layer收到审批消息后推给前端 self.send(text_datajson.dumps({ type: approval, order_no: event[order_no], title: 您有一条新的采购单待审批, })) # 在创建采购单的视图中审批后触发推送 from channels.layers import get_channel_layer channel_layer get_channel_layer() async_to_sync(channel_layer.group_send)( approval_notify, {type: approval_message, order_no: order.order_no} )前端小程序端用wx.connectSocket建立长连接收到消息后利用wx.vibrateShort()振动提醒主管同时弹窗显示您有一条编号为PO202408001的采购单待审批。这个功能的演示效果在答辩时堪称杀手锏——两台设备一台提交一台振动提醒全场目光都会被你吸引。需要注意的是WebSocket在课程设计阶段不要想做得太复杂能推一条审批通知就够了实时库存同步、实时聊天这些完全可以作为后期扩展方向写进文档。5. 万字论文写作框架与答辩准备5.1 论文结构的黄金比例关于万字文档这个卖点我给一个可以直接套用的文档框架总共约1万到1.2万字分为6章第1章 绪论约1200字企业信息化背景、ERP系统的国内外研究现状、本课题的研究意义。这一章难度最低、字数最好凑把企业数字化转型移动办公业务流程自动化这些关键词铺开写即可。第2章 相关技术介绍约1500字Django框架的MTV模式、MySQL的存储引擎、微信小程序开发框架、JWT认证机制、WebSocket长连接协议。每个技术写250字左右注意不要写成纯概念搬运最好加一句在本系统中的具体作用。第3章 系统分析约1500字可行性分析技术/经济/操作、需求分析功能需求非功能需求、用例图。这里要把用例图画全画出采购员、销售员、主管、管理员四个角色各自的用例。第4章 系统设计约2500字总体架构图、功能模块设计、数据库设计这部分建议写到1500-2000字是所有章节中分数占比最高的。每个表的字段名、类型、约束以表格形式呈现表之间的ER图单独放一整页。第5章 系统实现约2500字按照用户权限模块→基础资料→采购→库存→销售→小程序端→消息推送的顺序每个模块讲清楚实现逻辑核心代码片段运行界面截图。每个模块配1-2个代码块和一张截图字数自然就到位了。第6章 系统测试与总结约1300字测试计划、测试用例表功能测试性能测试兼容性测试、测试结论、项目总结与展望。注意文档中最容易被老师挑刺的是测试部分。很多同学只写经过测试系统功能正常这样等于告诉老师你没做过测试。正确的做法是做一张完整的测试用例表测试编号测试模块测试步骤预期结果实际结果结论T001用户登录输入正确账号密码登录成功成功通过T002越权访问普通员工访问审批接口拒绝访问返回403通过T003并发扣库存两个请求同时扣减同一商品库存5件扣减两次共10件扣减10件通过T004采购单审批主管审批通过采购单库存自动增加库存增加通过5.2 答辩前必须能随手画出的三张图答辩的核心不是念PPT而是在老师的追问下能画出系统骨架图。我强烈建议你在答辩前练熟下面三张图的画法不需要美观A4纸上用几分钟就能画出来第一张是系统架构图最上层是PC管理端和小程序端中间是Django业务层按App拆分的六个模块下层是MySQL数据库旁边标注JWT认证WebSocket推送两条横向链路。第二张是业务流程图以采购业务为主线画出一个环状流程——采购员创建采购单 → 主管审批 → 采购单状态改变 → 触发入库 → 库存表更新 → 流水表记录 → 首页报表刷新。第三张是数据库ER图把11张核心数据表的主外键关系画一遍不要求特别精确但要让老师看到你脑子里的数据流是通的。答辩时最忌讳照着PPT逐行念。如果老师问你为什么在这个地方用事务你就直接把第2节那段transaction.atomic的代码写出来告诉他因为采购入库涉及主表明细表库存表三处写入任何一个失败都会导致数据不一致所以必须保证原子性。这种回答方式比背一百个概念都有说服力。5.3 交付物整理源码、数据库、文档的目录规范线上交付时建议把整个项目整理成清晰的目录结构一是方便答辩演示时快速进入代码讲解二是给评审老师一个软件工程规范的第一印象ERP_Office_System/ ├── src/ # 源代码根目录 │ ├── erp_project/ # Django项目配置目录 │ ├── apps/ # 六个业务应用 │ ├── templates/ # PC端页面模板 │ ├── static/ # 静态资源css/js/图片 │ └── requirements.txt # Python依赖清单django, djangorestframework, etc. ├── wechat_mini/ # 微信小程序源码目录 ├── database/ │ ├── erp_office.sql # 数据库导出脚本 │ └── erp_office.sqlite3 # 本地调试用的SQLite副本可选 ├── docs/ │ ├── 开题报告.docx │ ├── 项目说明书.docx │ └── 答辩PPT.pptx └── README.md # 项目说明与部署启动步骤关于数据库文件要注意一个细节如果答辩机器上没有MySQL环境提供一个SQLite副本和一个MySQL导出脚本保证任何环境都能在两分钟内跑起来。README里写清楚三步启动命令pip install -r requirements.txt python manage.py migrate python manage.py runserver 0.0.0.0:8000再加上一句admin账号admin / admin123评审老师想自己动手体验时就能直接登录这要省去大量口头解释的时间。6. 开发流程中的低效陷阱与真实经验6.1 边写边改的进度黑洞与如何破局课程设计最容易翻车的不是写不出来而是写到一半推翻重来。我见过至少五个同学是在做完基础资料模块之后发现采购入库的流程设计不合理又Open数据库把表的外键关系改了结果所有已经写完的查询代码全部报错。所以务必在动手写代码之前把这个检查清单过一遍用户角色到底有几种每种角色能看到哪些页面采购入库之后库存是扣了再入库还是入库即加库存销售订单的取消是否要回填库存审批不通过时采购单是允许修改重新提交还是直接作废所有价格字段用的是DecimalField还是FloatField务必用Decimal浮点计算会出精度问题这些问题在文档第3章系统分析阶段就应该全部定稿。我的习惯是先用Excel列一张功能模块×角色×操作的权限矩阵表把每个单元格的可见/可操作/不可见填完再开始建表写代码。看起来多花了几个小时实际省掉的是后面几十个小时的返工时间。6.2 前后端联调时改一处崩三处的典型场景当我开发小程序端时曾遇到一个非常经典的问题小程序端接收到后端返回的采购单明细JSON是items: [{product_id: 1, quantity: 5}]但页面需要用product_name来显示商品名称。如果后端序列化时没有把商品名称带上前端就要根据product_id再发一个详情请求来查名称这样多一次来回不说还会出现数据加载顺序问题。最优解是后端在类型化接口中做关联查询嵌套序列化。写一个ProductSerializer嵌套到PurchaseOrderItemSerializerclass ProductBriefSerializer(serializers.ModelSerializer): class Meta: model Product fields [id, name, spec] class PurchaseOrderItemSerializer(serializers.ModelSerializer): product ProductBriefSerializer(read_onlyTrue) class Meta: model PurchaseOrderItem fields [product, quantity, unit_price]这样小程序端一次请求就能拿到商品名称和规格。当初我在这个问题上多花了一整天原因是图省事直接在Product模型里加了__str__方法然后序列化字段直接写product返回模型的字符串表示前端拿到的是商品名规格这种拼接文本还要自己正则切分非常痛苦。所以你写API时一定要想清楚前端真正需要哪些字段然后让后端一次性给全。6.3 答辩演示时的环境准备清单最后讲讲答辩演示这个容易忽略的环节。再多说一句演示环境请提前一天在答辩教室的机器上完整跑通一遍。我亲身经历过同学因为笔记本HDMI接口在教室的投影仪上没反应被迫用手机拍电脑屏幕演示的尴尬场面。演示前建议准备这些电脑充满电备用HDMI转接头和网线转接头都带上。MySQL服务设为开机自启而且不要设密码或把密码写到README里免得现场手忙脚乱输错。浏览器的书签栏预存好三个URLhttp://127.0.0.1:8000/admin/、http://127.0.0.1:8000/purchase/、一个测试采购单详情页。手机连接与电脑同一WiFi提前测试小程序API请求的域名白名单。本地调试时记得在微信开发者工具中勾选不校验合法域名。准备一份3分钟演示脚本顺序建议是用户登录 → 展示Admin后台数据列表 → 演示创建采购单 → 切换到手机小程序端演示审批 → 回到电脑端展示库存变化 → 打开报表页面展示统计图表。答辩现场演示用的数据库建议用一套种子数据把每个列表页都填满至少30条商品、10个客户、5个供应商这样列表页的翻页功能和统计报表的图表都不会是空白期。不要空库演示空列表页面看起来很low而且让老师觉得你的系统没有实际数据验证过。从技术选型到论文写作再到最后的答辩演示这套Django ERP 微信小程序的组合方案按部就班执行下来是能够在两周左右完整交付的。整个过程踩过的坑我都尽量写出来了照着走能帮你绕开大部分不必要的弯路。最后预祝你课程设计顺利答辩一次通过。