企业官网建设流程全解析

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 Framework（DRF）来输出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参数指定charset：

DATABASES = { '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 用户认证与权限控制的实现

这是整个项目的第一个核心难点，也是答辩老师大概率会考察的点。我的实现方案分两层：认证（你是谁） + 权限（你能干什么）。

认证层使用JWT（JSON 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_active=True) 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( order=order, product_id=item['product_id'], quantity=item['quantity'], price=item['price'], remark=item.get('remark', '') ) # 更新库存表：锁定量 + 减少可用量 self.update_stock(product_id, quantity=item['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. 常见问题与排查技巧实录

这个项目我前后帮人调试过不少次，也亲眼看过很多同学踩进同一个坑里爬不出来。我把高频问题整理成一个速查表，希望对你有实际帮助。

排查这些问题的过程中，我总结了两条通用原则，在这里分享给各位。

第一条原则是**"分层定位"**。小程序页面报错，先判断是前端渲染问题还是接口数据问题——按F12打开调试面板看Network面板，如果请求发出去了且后端返回了4xx或5xx，问题就在后端；如果请求都没发出去，问题就在前端的逻辑或权限校验。用这种二分法缩小范围，比瞎猜有效率得多。

第二条原则是**"看日志不如用断点"**。很多同学习惯把后端代码里到处加print来调试，打印出来的信息太零散。我更推荐直接用IDE自带的调试器打断点，观察变量在每一步的值。尤其排查库存联动这种需要多表联动的逻辑时，断点可以清晰地展示事务执行到哪一步、哪个变量的值与预期不符。调试花的时间越短，留给开发和写论文的时间就越多。

6. 毕设论文写作与答辩的经验分享

很多同学以为系统做完就万事大吉了，论文拖到最后一周狂写。以我见过的情况来看，这样做的结果往往是系统做得不错但论文逻辑混乱，答辩被问得手足无措。这个项目由于业务逻辑完整、模块边界清晰，论文其实非常好写，关键是要掌握节奏。

我先说论文结构。这份题目的论文，我认为比较稳妥的章节安排是：

• 第一章绪论：阐述中小型工厂管理数字化转型的必要性，引出定制化ERP的选题意义。
• 第二章相关技术介绍：Django框架、小程序开发框架、RESTful API设计、MySQL数据库。这一章不需要写得太深，重点是讲清楚"当初为什么选择这套技术栈"。
• 第三章系统需求分析：从业务痛点出发，画出用例图和数据流图，把功能需求和非功能需求（性能、安全、易用性）分别列出来。答辩时老师最喜欢问"你基于什么需求设计了这些功能"，这一章节就是你回答的依据。
• 第四章系统设计：架构设计（前后端分离）、功能模块设计、数据库设计（E-R图 + 核心表结构）。这里尽量讲清楚表与表之间的关联关系，展示你的数据库设计能力。
• 第五章核心功能实现：用截图 + 关键代码片段展示最核心的几个功能，比如订单审核流程、微信登录认证、库存预警触发。代码不用贴太长，挑有代表性的就行。
• 第六章系统测试：功能测试用例表、性能测试数据（接口响应时间等）、结果分析。
• 第七章总结与展望：讲一下做得好的地方和不足，以及未来可以扩展的方向。

答辩时老师比较关注的通常是几个点：

第一，技术选型理由。为什么要用Django而不是Spring Boot？为什么要小程序而不是原生APP？回答时不要只说"因为课程学了"，要讲清楚技术方案的匹配性——比如Django内置Admin方便管理基础数据、MVP框架开发效率高适合轻量办公场景、小程序免安装对工厂用户友好。

第二，系统的创新点在哪里。我非常建议自己在答辩前总结出两三个"能拿得出手"的创新点。这个题目最自然的创新点是"定制化"——你可以强调系统里的可配置项（审批流程、预警阈值、显示字段）是怎么实现的，让系统区别于一成不变的通用ERP软件。再比如你用了订阅消息主动推送生产进度通知，这也是一个体现实战思维的点。

第三，系统的局限性和未来改进方向。回答这个问题时最忌讳的是说"没有缺点"。你可以大方地承认：当前系统主要面向中小工厂的单工厂场景，尚未支持多工厂、多仓库的复杂组织架构；数据分析模块目前还停留在描述性统计层面，后续可以引入预测性分析（比如根据历史订单量和交期预估未来产能负荷）。这样回答既真诚，又体现出你对行业和技术的思考深度。

最后再分享一个小技巧：整个项目开发过程中，从第一天起就把"环境安装步骤""数据库初始化脚本""接口文档""部署手册"整理成独立的文档。毕业设计答辩之前，很多学校会要求提交部署说明或者项目演示，这些文档到时候直接就能用上，不用临时返工。我见过太多学生最后一周才意识到自己忘了记录部署过程，结果环境换了三台电脑才跑起来，场面非常狼狈。做毕设做的是全流程，系统跑通只是其中一环，能够让别人按照你的文档把项目完整复现出来，这才是更高一层的"完成"。