1. 先弄清楚这个项目到底解决什么问题1.1 工厂为什么需要定制化ERP最近后台私信里问得最多的就是毕业设计选题怎么选。很多同学一上来就问有没有好过的题目但我更建议大家先想清楚一个问题这个题目做出来能解决什么实际问题基于Django小程序的工厂定制化ERP办公系统APP小程序这个题目恰恰是一个能够把实际问题讲得很清楚的选题。提到ERP很多人第一反应是SAP、Oracle那种动辄几百万实施费用的巨型系统。但现实是真正的中小工厂——比如几十个人的机加工厂、电子元器件组装厂、包装材料厂——根本用不起也不需要用那么重的东西。它们真正需要的是能管住订单、管住库存、管住生产进度、管住发货物料的一套轻量工具。市面上通用ERP软件最大的问题就是流程僵化工厂的实际流程往往是老板说了算今天改一下明天又改一下通用软件改不动、定制又贵所以很多小工厂至今还在用Excel表格加微信群管理生产。定制化ERP这个词才是这个题目的核心价值所在。它不是一个包打天下的通用系统而是可以根据工厂特定流程去做调整的系统。比如普通的进销存软件订单审核必须一级一级走流程但小工厂可能就是老板直接在手机上批了就行再比如很多工厂有订单备注这种非标准化的信息记录需求通用软件里根本没有合适的字段只有定制化系统才能把这些细节都容纳进来。这个选题在毕设层面还有个特别明显的优势业务逻辑足够经典但场景足够接地气。ERP本身就是管理信息系统的经典课题考试、答辩老师都很熟悉你不需要费劲解释业务背景而工厂这个切入点又比千篇一律的学生管理系统图书管理系统更有差异化能让答辩老师眼前一亮。1.2 为什么是小程序而不是APP这是很多同学拿到题目之后的第一个疑问。既然都叫系统了为什么偏偏选小程序来做终端最直接的原因是微信小程序不需要安装扫码即用。工厂里的工人、车间主任、仓管员大部分人的手机里可能没装多少APP但微信人人都有。你让一个五十岁的车间主任去应用商店搜索、下载、注册一个工厂管理软件他大概率直接放弃但如果你在班组群里发一个链接让他点开就能用他反而愿意试一试。小程序那种用完即走的体验对于工厂里高频、轻量的办公场景来说是再合适不过的。从开发角度看小程序也有它独特的优势。小程序的前端开发语言虽然自成一派WXML WXSS JS但它的语法与Vue高度相似对于习惯Vue开发的同学来说上手成本非常低。而且小程序的开发调试流程非常轻微信开发者工具打开就能写不像原生Android/iOS那样要配SDK、配模拟器、处理签名。更现实一点说毕业设计要在一个学期内完成原生APP从开发到上架涉及的周期实在太长小程序能让你把时间集中花在业务逻辑和系统架构上而不是折腾各种环境配置。1.3 哪些人适合拿这个题做毕设我接触过不少选这个题目的学生结合他们的反馈我认为这个题目适合以下几类人Java或Python后端有点基础但前端不太行的同学。Django的模板和REST框架帮你把大部分后端工作做完小程序端只需要掌握基础语法和API调用不需要特别高深的前端功底。想找Java后端/全栈开发方向就业的同学。Django是Python后端的主流框架小程序是当前企业数字化最常见的载体这套技术栈写进简历里面试官看到了会认为你对实际项目落地的理解比较到位。准备时间只有3到4个月的同学。这个题目的功能边界清楚可以按照必须做的核心功能和可以延展的加分功能来规划排期即便中途遇到问题也不至于全盘崩溃。希望论文有实际数据支撑的同学。ERP类系统天然适合收集操作日志、统计数据做分析论文里可以光明正大地放上系统运行测试数据、用户反馈、性能表现等内容比空谈理论扎实得多。当然如果你完全没学过Python也没接触过任何Web开发我建议不要直接拿这个题入手——不是题目本身有多难而是你需要同时补后端、数据库、前端、小程序四块知识时间上会比较紧张。2. 技术选型Django 小程序这个组合为什么能打2.1 Django:Python后端里的全家桶Django在国内技术圈的讨论热度虽然经常被Spring Boot压一头但在毕业设计这个维度上它其实是相当能打的选项。原因很简单Django把Web开发大部分脏活累活都替你干了。最典型的例子是Django自带的Admin后台。很多厂里的基础数据比如物料清单、供应商信息、员工名单在小程序端可能不太方便批量录入但Django Admin后台原生就能支持表格形式的管理页面你只需要定义好模型后台自动生成增删改查界面省掉了大量手写管理页面的时间。这一点在开发周期紧张的毕设阶段尤其重要。然后是Django的ORM对象关系映射机制。我见过不少同学写后端最怕的就是拼SQL语句——多表查询一复杂起来SQL写得自己都心虚。Django的ORM把数据库操作封装成Python对象的方法调用比如你要查今天所有已完成订单对应的客户名称和联系方式只需一行filter加values就能搞定不需要手动JOIN两张表。对于业务逻辑以数据管理为核心的ERP系统来说ORM带来的开发效率提升是实打实的。另一个容易被忽略的好处是Django自带的安全机制。比如基于表单的CSRF防护、SQL注入防护、XSS过滤等默认都是开启的。作为毕设项目答辩老师很可能会问你的系统安全方面做了什么你可以直接理直气壮地答框架层面已经内置了常见Web攻击的基础防护然后再展示一下自己写的登录验证逻辑这个回答就非常完整了。2.2 小程序最贴近业务场景的终端小程序这边微信生态给开发者提供了几个很实用的能力恰好能切中工厂ERP的办公场景。第一是微信登录。工厂员工不用单独注册账号密码直接通过微信授权就能完成身份绑定。我在实际开发中就用了微信的wx.login接口获取临时登录凭证再通过后端调微信接口换取用户唯一标识和本地员工表做好映射。员工换手机也不影响因为身份是跟着微信走的这个体验比传统的用户名密码登录好不少。第二是订阅消息。ERP里经常有订单状态变更通知审批结果通知这类场景。小程序可以通过订阅消息模板给用户推送提醒比如订单审核通过了、库存不足需要补货了员工微信里就能收到通知。这个功能在答辩演示的时候特别加分因为它展示了主动通知而非被动查询的能力系统价值感立马就不一样了。第三是扫码能力。工厂里的物料、成品、设备一般都有编号或二维码。小程序原生支持wx.scanCode调用摄像头扫码扫完可以直接定位到对应的物料详情、订单详情。这个功能实现起来不难核心代码就十几行但演示效果非常好能体现系统的数字化深度。2.3 前后端分离的架构怎么搭明确了Django和小程序各自的角色之后整体架构就非常清晰了。我建议直接采用前后端分离的模式后端用Django提供RESTful API接口前端小程序独立开发两者通过JSON数据交互。这种情况下Django不负责渲染HTML页面而是专注于数据模型和业务逻辑统一通过Django REST FrameworkDRF来输出API。DRF是Django社区最主流的API开发框架它把序列化、校验、分页、认证这些繁琐的事情都规范化了。在我做的这个项目里就是用DRF的ModelViewSet配合路由注册一个订单模块的增删改查接口核心代码量不超过一百行就能全部跑通。小程序端则通过wx.request发送网络请求来调用这些API。这里需要注意一个关键点小程序的网络请求有域名白名单校验开发阶段可以在微信开发者工具里勾选不校验合法域名就能直接连本地的Django开发服务器比如http://127.0.0.1:8000。但到了真机预览或者上线阶段就必须有一个HTTPS备案域名才行。这一点我在后面常见问题部分会详细说算是新课必踩的坑。3. 功能模块拆解与数据库设计3.1 核心功能清单从一个订单的旅程说起做ERP系统最忌讳的就是贪多嚼不烂。我的建议是按一个订单从进到出的完整生命周期来设计功能这样每个模块之间都有强逻辑关联无论答辩还是写论文都好讲故事。我按这个思路把功能拆成了金字塔结构金字塔底座基础数据管理。包括用户信息、员工档案、角色权限、部门岗位、客户信息、供应商信息、物料/产品名录。这些数据是上层业务运转的基石没有它们订单、生产、库存都无从谈起。金字塔中层核心业务流转。这是系统的重头戏订单管理创建订单、订单审核、订单状态跟踪待审核→生产中→已完工→已发货→已完成、订单明细包含产品、数量、交期、单价、备注。生产管理生产任务单一个订单可以拆成多个生产批次、生产进度填报开工、完工、质检、生产报工记录。库存管理原料入库、原料出库、成品入库、成品出库、库存盘点、库存预警低于安全库存自动提示。采购管理根据库存预警自动生成采购申请单、采购订单、到货入库。金字塔塔尖统计分析与看板。包括订单完成率统计、月度销售额统计、库存周转率分析、生产进度实时看板。这部分是答辩时的亮点也是论文里系统价值的重要支撑。定制化的体现在于这些模块不是硬邦邦的固定流程而是允许管理员在后台配置。比如订单审核可以配置为需要审核或无需审核库存预警阈值可以针对不同物料单独设置。这种可配置性正是定制化ERP区别于通用软件的核心差异也是答辩时可以向老师强调的点。3.2 数据表设计思路核心表有哪些数据表设计是整个项目中我花时间最多的地方因为ERP系统的表关联非常密集设计不当后续改起来会痛不欲生。我不打算把所有表的结构都罗列一遍那得写一篇单独的文档只说几个关键的模型设计思路。用户相关用户表依附于微信登录我建议单独建一个员工表与用户表做一对一关联。用户表存微信身份信息员工表存姓名、工号、部门、岗位、联系方式等业务信息。这样做的好处是即便员工离职账号可以禁用但员工档案保留符合工厂的实际管理习惯。订单相关这里要注意主表与明细表分离。主表存订单编号、客户、总金额、状态、交期、备注明细表存每一行产品、数量、单价、小计金额、工艺要求。这种父子表结构是管理系统的经典设计很多新人第一次做容易把所有字段塞进一张表后面查询统计的时候就会非常被动。库存相关我强烈建议设计一张出入库流水表。这张表只做一件事记录每一次库存变动的方向入/出、数量、关联的单据类型采购入库/生产领料/销售出库等、关联单据编号和操作人。库存的实时数量可以通过流水表汇总计算出来也可以单独维护一个库存表存实时数量。两种方案各有优劣我在项目里采用的是库存表 流水表双保险流水表留痕库存表加速查询。权限相关Django原生支持用户权限和分组机制Group/Permission可以直接复用。我把角色划分为系统管理员拥有全部权限、生产主管管理生产任务和报工、仓管员管理出入库、普通员工查看订单和填报进度。角色与权限的对应关系可以在Django Admin里维护开发工作量小而且逻辑清晰。4. 核心功能的实操实现与踩坑记录4.1 环境准备与项目初始化这一块我默认你已经有Python基础如果连Python都没装好建议先去补一下基础不然下面每一步你都会觉得像在走迷宫。我的环境推荐是Python 3.10 Django 4.2 Django REST Framework MySQL 8.0本地开发也可以用SQLite但建议尽早切到MySQL避免后期部署才暴露兼容性问题。小程序端用微信开发者工具的稳定版本基础库版本不用太纠结稳定版就行。项目初始化我建议按这个顺序来# 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows下用 venv\Scripts\activate # 安装核心依赖 pip install django djangorestframework django-cors-headers pymysql # 创建项目 django-admin startproject factory_erp cd factory_erp python manage.py startapp api python manage.py startapp users这里有两个我在实操中认为很重要的配置细节第一跨域问题。小程序端请求Django接口本身不受浏览器同源策略限制但如果你后续要Web管理端联调就会遇到跨域。建议从一开始就配置好django-cors-headers省得后面开发过程中被各种跨域报错打断。具体是在INSTALLED_APPS里加corsheaders然后在MIDDLEWARE里把CorsMiddleware尽可能放在靠前的位置一般放在CommonMiddleware之前最后在配置文件中设置允许的来源域名。第二数据库连接。MySQL要特别注意字符集配置建议统一使用utf8mb4不然存个生僻字或者特殊符号就可能报错。Django的DATABASES配置里要加上OPTIONS参数指定charsetDATABASES { default: { ENGINE: django.db.backends.mysql, NAME: factory_erp, USER: root, PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { charset: utf8mb4, } } }4.2 用户认证与权限控制的实现这是整个项目的第一个核心难点也是答辩老师大概率会考察的点。我的实现方案分两层认证你是谁 权限你能干什么。认证层使用JWTJSON Web Token。项目里我用了djangorestframework-simplejwt这个库它和DRF的集成非常顺滑。用户通过小程序端wx.login拿到微信临时凭证后后端调用微信接口换取openid然后查员工表确认该openid是否已绑定如果绑定了就签发JWT后续请求都在请求头里带Authorization: Bearer token。Django的认证类配置如下REST_FRAMEWORK { DEFAULT_AUTHENTICATION_CLASSES: [ rest_framework_simplejwt.authentication.JWTAuthentication, ], DEFAULT_PERMISSION_CLASSES: [ rest_framework.permissions.IsAuthenticated, ], }这里有一个我踩过的坑想提醒大家微信登录获取openid的请求是后端代发请求到微信服务器的前端传过来的是一个code。这个code五分钟内有效且只能用一次如果你在调试时发现code无效的报错十有八九是同一个code被发送了两次比如页面重复触发了登录逻辑。权限层我选择在DRF的视图类里通过get_permissions方法动态设置。比如订单创建需要登录用户即可订单审核就需要有审核权限的用户。我建议在users应用里自定义一个is_auditor这样的权限类然后通过Django的Group来管理哪些用户属于审核人组。这样在代码层面一眼能看到每个接口的权限要求论文里也好写清楚权限矩阵。4.3 业务核心订单模块的增删改查实现订单模块是整个ERP系统里最复杂的业务模块因为它牵涉到主表、明细表、库存表、生产任务四方的联动。我把实现拆成了三层逻辑每层解决一类问题。第一层接口定义。订单相关的API我用DRF的ModelViewSet来写。它默认提供list/retrieve/create/update/destroy五个接口方法但对于订单这种不允许随意删除的业务单据我重写了destroy方法改为逻辑删除用一个is_active字段标记不真正从数据库删除。工厂里一张订单一旦创建往往关联了生产计划和采购计划物理删除会造成数据混乱。第二层序列化逻辑。订单创建时前端提交的是一个嵌套结构订单头部信息 商品明细数组。DRF的WritableNestedModelSerializer功能是支持的但校验逻辑写起来有些繁琐。我用了更朴素一点的方式在create方法里手动处理明细数据先创建主表记录再遍历明细列表逐条创建明细记录。这样做的代价是多写一点代码但好处是事务控制非常明确——如果明细里有任何一条校验失败主表记录也要回滚。实现代码如下简化版from django.db import transaction class OrderViewSet(viewsets.ModelViewSet): queryset Order.objects.filter(is_activeTrue) serializer_class OrderSerializer transaction.atomic def perform_create(self, serializer): order serializer.save() # 保存主表 items_data self.request.data.get(items, []) for item in items_data: order_item OrderItem.objects.create( orderorder, product_iditem[product_id], quantityitem[quantity], priceitem[price], remarkitem.get(remark, ) ) # 更新库存表锁定量 减少可用量 self.update_stock(product_id, quantityitem[quantity])第三层库存联动。这是最容易出错的地方。订单创建后如果对应的成品库存不足就需要生成生产任务或者通知采购。我的逻辑是在订单审核通过时触发库存检查库存不足时自动生成一条生产任务单状态为待排产。生产完工后成品入库增加库存然后订单才能进入可发货状态。为了让这个状态流转清晰我给订单模型加了一个状态字段枚举值包括待审核、已审核、生产中、可发货、已发货、已完成、已取消。整个流程在PPT里画出来就是一个箭头图答辩时讲起来非常直观。4.4 小程序端对接联调的要点小程序端我按照页面维度来组织代码核心页面包括登录页、首页工作台展示看板统计、订单列表页、订单详情页、生产任务页、库存管理页、个人中心页。每个页面对应调用后端的一组API我用一个统一的request工具函数封装了wx.request集中处理Token的请求头注入、错误码提示和登录失效跳转。这里有一个非常实际的开发建议先定义好后端的API文档再开发小程序页面。我在项目里用DRF的SchemaGenerator自动生成了OpenAPI文档然后小程序端严格按照文档里的接口来联调。如果你在开发过程中频繁出现前端不知道后端返回什么字段这种问题大概率就是API文档没有前置定义这是很多开发新手最容易陷入的低效循环。小程序端登录的关键代码大致如下// 小程序端获取code并请求后端登录接口 wx.login({ success: (res) { if (res.code) { wx.request({ url: http://localhost:8000/api/login/, method: POST, data: { code: res.code }, success: (response) { const { token } response.data; wx.setStorageSync(token, token); } }); } } });这里要提一下HTTPS和域名问题。微信开发者工具里可以勾选不校验合法域名来方便本地调试但到了真机预览阶段这个选项就不起作用了。解决思路有两个一是买一台轻量云服务器挂上备案域名和SSL证书部署Django后端二是使用内网穿透工具暂时把本地开发服务器暴露到公网因为合规原因这里不做工具推荐你可以自行调研。我自己的做法是直接用云服务器部署并且把数据库、静态文件、媒体文件的配置都一并搞定这样答辩演示的时候可以在任何设备上稳定访问不会出幺蛾子。5. 常见问题与排查技巧实录这个项目我前后帮人调试过不少次也亲眼看过很多同学踩进同一个坑里爬不出来。我把高频问题整理成一个速查表希望对你有实际帮助。问题现象可能原因排查与解决思路微信登录提示code无效code被重复使用或过期检查前端登录逻辑是否重复调用wx.login确保每次登录都重新获取code不要缓存小程序真机预览时所有请求全部失败域名未备案/未配置HTTPS开发者工具可以跳过域名校验但真机必须使用已备案的HTTPS域名确认Django的ALLOWED_HOSTS包含你的域名创建订单时报外键约束错误传入的product_id不存在或不属于当前工厂在序列化器中增加validate方法显式校验产品ID的有效性增加工厂ID参数过滤库存数量对不上没有用事务包裹库存操作检查所有涉及库存变动的视图函数是否添加了transaction.atomic确认流水表和库存表更新顺序Admin后台登录后修改数据没反应CSRF Token校验失败Django Admin自带CSRF防护浏览器开发者工具里确认Cookie和CSRF token字段都存在小程序端token过期后页面无响应401状态码未统一处理在request工具函数里统一拦截401响应自动跳转到登录页并清理本地缓存DRF的perform_create里写日志报错手动创建Model时遗漏必填字段优先使用serializer.save()而不是直接Model.objects.create()因为序列化器会统一处理字段校验排查这些问题的过程中我总结了两条通用原则在这里分享给各位。第一条原则是**分层定位**。小程序页面报错先判断是前端渲染问题还是接口数据问题——按F12打开调试面板看Network面板如果请求发出去了且后端返回了4xx或5xx问题就在后端如果请求都没发出去问题就在前端的逻辑或权限校验。用这种二分法缩小范围比瞎猜有效率得多。第二条原则是**看日志不如用断点**。很多同学习惯把后端代码里到处加print来调试打印出来的信息太零散。我更推荐直接用IDE自带的调试器打断点观察变量在每一步的值。尤其排查库存联动这种需要多表联动的逻辑时断点可以清晰地展示事务执行到哪一步、哪个变量的值与预期不符。调试花的时间越短留给开发和写论文的时间就越多。6. 毕设论文写作与答辩的经验分享很多同学以为系统做完就万事大吉了论文拖到最后一周狂写。以我见过的情况来看这样做的结果往往是系统做得不错但论文逻辑混乱答辩被问得手足无措。这个项目由于业务逻辑完整、模块边界清晰论文其实非常好写关键是要掌握节奏。我先说论文结构。这份题目的论文我认为比较稳妥的章节安排是第一章绪论阐述中小型工厂管理数字化转型的必要性引出定制化ERP的选题意义。第二章相关技术介绍Django框架、小程序开发框架、RESTful API设计、MySQL数据库。这一章不需要写得太深重点是讲清楚当初为什么选择这套技术栈。第三章系统需求分析从业务痛点出发画出用例图和数据流图把功能需求和非功能需求性能、安全、易用性分别列出来。答辩时老师最喜欢问你基于什么需求设计了这些功能这一章节就是你回答的依据。第四章系统设计架构设计前后端分离、功能模块设计、数据库设计E-R图 核心表结构。这里尽量讲清楚表与表之间的关联关系展示你的数据库设计能力。第五章核心功能实现用截图 关键代码片段展示最核心的几个功能比如订单审核流程、微信登录认证、库存预警触发。代码不用贴太长挑有代表性的就行。第六章系统测试功能测试用例表、性能测试数据接口响应时间等、结果分析。第七章总结与展望讲一下做得好的地方和不足以及未来可以扩展的方向。答辩时老师比较关注的通常是几个点第一技术选型理由。为什么要用Django而不是Spring Boot为什么要小程序而不是原生APP回答时不要只说因为课程学了要讲清楚技术方案的匹配性——比如Django内置Admin方便管理基础数据、MVP框架开发效率高适合轻量办公场景、小程序免安装对工厂用户友好。第二系统的创新点在哪里。我非常建议自己在答辩前总结出两三个能拿得出手的创新点。这个题目最自然的创新点是定制化——你可以强调系统里的可配置项审批流程、预警阈值、显示字段是怎么实现的让系统区别于一成不变的通用ERP软件。再比如你用了订阅消息主动推送生产进度通知这也是一个体现实战思维的点。第三系统的局限性和未来改进方向。回答这个问题时最忌讳的是说没有缺点。你可以大方地承认当前系统主要面向中小工厂的单工厂场景尚未支持多工厂、多仓库的复杂组织架构数据分析模块目前还停留在描述性统计层面后续可以引入预测性分析比如根据历史订单量和交期预估未来产能负荷。这样回答既真诚又体现出你对行业和技术的思考深度。最后再分享一个小技巧整个项目开发过程中从第一天起就把环境安装步骤数据库初始化脚本接口文档部署手册整理成独立的文档。毕业设计答辩之前很多学校会要求提交部署说明或者项目演示这些文档到时候直接就能用上不用临时返工。我见过太多学生最后一周才意识到自己忘了记录部署过程结果环境换了三台电脑才跑起来场面非常狼狈。做毕设做的是全流程系统跑通只是其中一环能够让别人按照你的文档把项目完整复现出来这才是更高一层的完成。