企业官网建设流程全解析

简介：一套基于微信小程序的物业管理系统毕业设计项目，后端采用Java，面向计算机类专业毕业生、小程序开发者及有物业信息化需求的学习者，可用于毕设参考、课程设计或原型搭建。压缩包共402个文件、约726KB，文件类型覆盖Java接口与实体源码、wxss样式表、wxml页面结构、js交互逻辑、xml/json配置数据、sql初始化脚本及doc毕业论文文档，既有可直接运行的代码，也有撰写论文时可参考的文档，目录划分清楚，便于按模块查阅和二次开发。系统功能完整，业主端支持公告查看、维修提交（可附图片）、缴费查询、车位查看与满意度反馈；物业端支持卫生记录、车位查询、维修处理、缴费管理、业主需求及公告管理；管理员端则可维护业主、物业人员等多类账号信息。目前已有380人学习下载，对理解微信小程序前后端协作、角色权限划分和物业管理业务建模具有直接参考价值。

1. 微信小程序物业系统：毕设题目的真实工程量

看到「基于微信小程序的小区物业管理系统设计与实现」这个题目时，很多人的第一反应是“又多了一个 CRUD 练习”，但真正动手才发现：小程序端、管理端、后端接口、数据库、部署，再加上一篇毕业论文，五条线同时压过来。这个题目能解决的实际问题是——把业主报修、物业缴费、公告通知、投诉建议这些日常事务从线下搬进微信，让物业公司少接电话，让业主少跑腿。它适合计算机相关专业的毕设选题，也适合想接物业服务外包的开发者当样板工程。

这个题目最容易被低估的是“设计与实现”这五个字。答辩时老师不会只问“你怎么写的代码”，还会问“为什么这样设计”“数据怎么流转”“遇到什么问题怎么排查”。所以这篇文章不打算只讲代码，我把从选型到建表、从核心链路到论文框架的完整路径拆开，按我实际带人做这类项目的顺序来讲：先定技术路线，再拆数据库，再写核心代码，最后讲论文怎么写才能过盲审。

2. 先定技术路线：原生小程序与后端选型对比

2.1 为什么首选原生微信小程序而非跨端框架

做小区物业这类场景，小程序端基本都是表单、列表、支付跳转，交互密度低，没有复杂的动画和图表渲染。原生小程序语法虽然啰嗦，但调试链路最短：开发者工具打开就能跑，不需要编译桥接层。我的做法是优先用原生，除非你手上有现成的 uni-app 或 Taro 组件库非要复用，否则跨端框架在毕设这种规模里只会增加翻车概率。

原生小程序的另一个优势是云开发能力直接可用。如果你不想自己买服务器，整个后端可以用云函数 + 云数据库解决，省掉域名备案和 HTTPS 证书的环节。但这里有个边界要提前想清楚：如果你打算在论文里写“前后端分离架构”“基于 MVC 模式的后端设计”，那云开发的模型会让论文技术描述变单薄。我的建议是——追求省事用云开发，追求论文深度自己写一个 Node.js 后端，两种路线下文都会涉及。

技术选型对比见下表，这是我给来问的人最常贴的一张表：

如果选方案 B 或 C，服务器、域名、备案这三件事建议提前两周启动，因为备案审核周期不可控。我见过不少人代码写完了，卡在备案上，最后用 IP + 端口在答辩现场演示，体验很差。

2.2 工程目录怎么拆：小程序端、管理端、后端互不干扰

这一个系统实际上包含三个子端：业主用的小程序端、物业用的管理端（可以是小程序里的一个角色入口，也可以是独立的 Web 管理后台）、后端服务。我一般建议把管理端也做进小程序，用角色权限切换，这样论文里可以写“多角色权限模型”，答辩时也好演示——一个微信里登录两个账号切来切去，比现场开电脑连后台更直观。

后端工程结构我习惯按业务模块拆，而不是按技术层拆。也就是说，不要搞一个 controllers 文件夹装所有接口，而是按报修、缴费、公告、用户四个业务域各自成包。按模块拆的好处是：写论文数据流图时，每个模块对应一张时序图，逻辑清晰，不会出现“这个函数到底属于哪块”的纠缠。

mini-program/ # 小程序端 ├── pages/ │ ├── login/ # 登录页 │ ├── home/ # 首页（公告+快捷入口） │ ├── repair/ # 报修 │ ├── payment/ # 缴费 │ ├── complaint/ # 投诉建议 │ └── mine/ # 我的（个人信息+我的工单） ├── utils/ │ ├── request.js # 封装 wx.request │ └── auth.js # 登录态管理 └── app.json server/ # 后端（以 Node.js 为例） ├── routes/ │ ├── user.js # 登录、个人信息 │ ├── repair.js # 报修工单 │ ├── payment.js # 缴费订单 │ └── notice.js # 公告 ├── controllers/ # 业务处理 ├── models/ # 数据库模型 └── app.js

这个结构直接决定了论文的系统设计章节怎么画图。逻辑是：pages/对应用户界面设计，routes/对应接口设计，models/对应数据库设计。论文里的“系统模块划分”这一小节，就是从目录结构里提炼出来的，不需要另外发明一套说法。

2.3 选型定下来之后，先写接口文档再动手开发

这是一个经常被跳过的步骤，但恰恰是最省时间的。我见过太多人先建表再写接口，写到一半发现接口返回字段和页面需要的对不上，回头改表再改页面，浪费时间还容易漏。正确顺序是：先梳理页面需要什么数据，再定接口返回结构，最后反推表结构。接口文档不一定要用正式工具，一个 Markdown 表格就够了，但字段名、类型、是否必填、错误码必须写清楚。

接口文档先行的另一个好处是：管理端和小程序端可以并行开发。两个人各自按接口文档对接数据，最后联调时冲突会少很多。如果是一个人做，接口文档也能帮你理清思路——写完文档再写代码，代码基本一次跑通。

3. 把业务拆进数据库：表结构与工单状态机

3.1 核心表设计：用户、房屋、报修、缴费、公告

物业系统的数据库设计核心是“用户—房屋—业务”这三层关系。业主绑定房屋后，报修和缴费都要关联到房屋维度，而不是单纯挂在用户 ID 上。这是因为物业费是按房屋面积计算的，一个业主名下可能有多套房，一套房也可能有多个居住成员，报修需要定位到具体楼栋和房间。

下面是 MySQL 方案的建表核心语句，云开发集合结构大同小异，把主键换成系统生成的_id即可：

CREATE TABLE `user` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `openid` VARCHAR(64) NOT NULL UNIQUE, `name` VARCHAR(20), `phone` VARCHAR(20), `role` TINYINT DEFAULT 1 COMMENT '1-业主 2-物业', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE `house` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `building` VARCHAR(10) NOT NULL COMMENT '楼栋号，如 3栋', `unit` VARCHAR(10) NOT NULL COMMENT '单元号', `room` VARCHAR(10) NOT NULL COMMENT '房号', `area` DECIMAL(10,2) COMMENT '面积(㎡)', `owner_user_id` INT COMMENT '绑定业主' ); CREATE TABLE `repair_order` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `house_id` INT NOT NULL, `user_id` INT NOT NULL, `category` VARCHAR(20) COMMENT '水电/门窗/电梯/其他', `description` TEXT, `images` JSON COMMENT '图片地址数组', `status` TINYINT DEFAULT 0 COMMENT '0-待派单 1-处理中 2-待验收 3-已完成 4-已取消', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `assignee` VARCHAR(20) COMMENT '维修人', `finish_time` DATETIME ); CREATE TABLE `payment_order` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `house_id` INT NOT NULL, `period` VARCHAR(20) COMMENT '账单周期，如 2025-03', `amount` DECIMAL(10,2), `status` TINYINT DEFAULT 0 COMMENT '0-待支付 1-已支付 2-已退款', `pay_time` DATETIME, `transaction_id` VARCHAR(64) COMMENT '微信支付单号' );

这里有几个我踩过的坑，先写在前面。第一，role字段不要设计得过于复杂，这个系统里只有业主和物业两种角色，RBAC 模型在这个规模下是过度设计，论文里提一句“采用角色区分权限”就够了，单独建一张角色表和权限表反而会被答辩老师追问“请说明你权限控制的具体粒度”。第二，images用 JSON 类型不要用逗号拼接字符串，否则后面做图片预览时要多做一次拆分。第三，订单金额用DECIMAL(10,2)不要用FLOAT，金额精度问题在支付场景是致命的。

3.2 报修工单状态机：每个状态对应一次前端操作

报修工单是整个系统里业务逻辑最复杂的部分，建议用状态机来管理。状态机的核心价值是让代码逻辑和论文描述保持一致：状态流转必须经过指定操作，不能随意跳转。例如待派单状态只能被物业端“派单”操作推进到处理中，业主不能直接把它改成已完成。

后端代码里，我习惯用一个状态流转表来约束合法跳转，而不是写一堆 if else：

// 状态流转配置：key 为当前状态，value 为允许跳转的目标状态集合 const REPAIR_TRANSITIONS = { 0: [1, 4], // 待派单 -> 处理中 / 已取消 1: [2, 4], // 处理中 -> 待验收 / 已取消 2: [3], // 待验收 -> 已完成 3: [], // 终态 4: [] // 终态 }; function transition(order, nextStatus, operatorRole) { const allowed = REPAIR_TRANSITIONS[order.status] || []; if (!allowed.includes(nextStatus)) { throw new Error(`非法状态流转: ${order.status} -> ${nextStatus}`); } // 额外校验操作者角色 if (nextStatus === 2 && operatorRole !== 'property') { throw new Error('仅物业可标记完成'); } return nextStatus; }

这段代码有两个参数值得说。REPAIR_TRANSITIONS是状态流转的“白名单”，任何不在白名单里的跳转直接拒绝，这就是状态机相对散装 if 判断的优势——你不需要枚举所有非法场景，非法场景天然被白名单排除。operatorRole是角色校验，即使小程序端把按钮隐藏了，后端也要校验，因为接口可以被直接调用。

3.3 缴费模块的设计取舍：虚拟账单与微信支付的边界

缴费模块要提前做一个重要决策：是否接入真实微信支付。对接微信支付需要商户号，个人开发者的商户号申请流程不简单，而且毕设场景里真实支付流水会引入退款、对账等一连串问题。我的建议是：做成“模拟支付 + 预留支付接口”的方案，论文里写“本系统采用微信支付统一下单接口的模拟实现，实际接入需配置商户号”，答辩老师普遍能接受这个边界。

模拟支付的实现逻辑是：业主点击缴费后，前端调起一个支付确认弹窗，点击确认后直接调用后端“模拟支付成功”接口，把订单状态从待支付改为已支付。但要保留真实的调起支付接口入口，接口名字和入参按微信支付的规范命名。

// routes/payment.js 简化版 router.post('/pay', async (req, res) => { const { orderId, payType } = req.body; // payType: 'mock' | 'wechat' if (payType === 'wechat') { // 真实支付：此处调用 wxpay.createOrder 生成支付参数 // 毕设中建议直接返回 not_configured，由前端走 mock 分支 return res.json({ code: 1001, msg: '未配置商户号，请使用模拟支付' }); } // 模拟支付：直接标记支付成功 const order = await PaymentModel.findByPk(orderId); if (order.status !== 0) { return res.json({ code: 1002, msg: '订单状态异常，请刷新后重试' }); } order.status = 1; order.pay_time = new Date(); order.transaction_id = 'MOCK_' + Date.now(); await order.save(); res.json({ code: 0, msg: '支付成功', data: { transactionId: order.transaction_id } }); });

支付模块的关键在事务处理。如果后续要做“支付后自动更新缴费状态并发送通知”，必须把订单更新和通知动作放在一个事务里，否则会出现钱扣了但订单状态没变的脏数据。云开发环境里事务语法不同，但原则一致：关联写操作要么都成功，要么都回滚。

4. 跑通核心链路：登录、报修、缴费的代码落地

4.1 微信登录与 openid 获取：第一个绕不过去的接口

小程序登录是前后端第一次联调的地方，也是新手最容易懵的环节。整个流程是固定的：前端wx.login拿到临时 code → 传给后端 → 后端用 code 调微信接口换取 openid 和 session_key → 后端用 openid 关联用户 → 返回自定的 token 给前端。这里的核心点：code 只能用一次，有效期五分钟，session_key 不能下发到前端，openid 是用户的唯一标识。

// 小程序端 utils/auth.js 简化版 function login() { return new Promise((resolve, reject) => { wx.login({ success: async (res) => { if (res.code) { const loginRes = await request({ url: '/api/user/login', method: 'POST', data: { code: res.code } }); wx.setStorageSync('token', loginRes.data.token); resolve(loginRes.data); } else { reject(new Error('wx.login 失败: ' + res.errMsg)); } } }); }); }

后端拿到 code 后，需要通过https://api.weixin.qq.com/sns/jscode2session换取 openid，这个请求需要在后端发，不能在小程序端直接发，因为接口需要 appsecret，appsecret 泄露会导致账号被恶意调用。后端代码中我习惯把 appid 和 secret 放到环境变量里，而不是写死在代码中。

登录成功后的 token 我用的是普通随机串，不是 JWT。JWT 虽然显得“高级”，但在小程序场景里需要考虑 token 过期主动续期的问题，处理不好反而答辩被追问。随机串 + Redis 缓存在这个规模下足够用，而且代码容易解释。

4.2 报修工单创建：图片上传与表单提交的顺序问题

报修页面的表单包含文本和图片。图片上传不能和表单一起提交，必须先把图片传到云存储或后端服务器，拿到图片 URL 后再把 URL 和文本一起提交到业务接口。这个先后顺序很多人搞反，导致要么图片传了但工单没建成功，要么工单建了图片 URL 是本地临时路径。

// 小程序端 report-repair.js 关键片段 async function submitRepair() { const description = this.data.description; const images = this.data.images; // 临时文件路径数组 // 第一步：逐个上传图片 const uploadedUrls = []; for (let file of images) { const result = await new Promise((resolve, reject) => { wx.uploadFile({ url: `${baseURL}/api/upload`, filePath: file, name: 'file', success: (res) => { const data = JSON.parse(res.data); resolve(data.url); // 返回服务器上的图片 URL }, fail: reject }); }); uploadedUrls.push(result); } // 第二步：图片 URL 和文本一起提交 const orderData = { category: this.data.category, description: description, images: uploadedUrls // 注意：这里是 URL 数组，不是临时路径 }; const res = await request({ url: '/api/repair/create', method: 'POST', data: orderData }); wx.showToast({ title: '提交成功' }); }

这段代码在处理中需要注意一个性能细节：图片上传是串行执行的，如果一次传三张以上大图，会比较慢。优化空间是改成Promise.all并发上传，但并发数不要超过 3，否则可能触发微信的并发限制。实际项目里我会在uploadedUrls提交前加一个判断：如果任一图片上传失败，整个工单不允许提交，避免出现“文本成功、图片缺失”的半截工单。

4.3 首页公告与缴费记录：分页查询的两种写法

列表类数据的核心是分页。首页公告和缴费记录都是典型的滚动加载列表。分页有两种常见写法：page/pageSize偏移量分页和cursor游标分页。偏移量分页简单，适合后台管理端的页码跳转；游标分页适合小程序这种“上拉加载更多”的场景。为什么？因为偏移量分页在数据发生变化时，用户滚动到第二页可能看到第一页已出现过的重复数据，游标分页用“上次拿到的时间点或 ID”作为下次查询起点，可以避开这个坑。

-- 偏移量分页（适合管理端） SELECT * FROM payment_order WHERE house_id = ? ORDER BY create_time DESC LIMIT #{offset}, #{pageSize}; -- 游标分页（适合小程序端） SELECT * FROM payment_order WHERE house_id = ? AND create_time < #{lastCreateTime} ORDER BY create_time DESC LIMIT #{pageSize};

游标分页的关键是排序字段必须唯一且稳定。我习惯用create_time + id做组合排序，因为同一秒内可能产生多条记录，只用create_time会出现漏数据。前端拿到列表后，记录最后一条的create_time作为下一次请求的游标。调用方参数说明：lastCreateTime为空时表示取第一页，非空时取该时间点之前的数据，返回列表的同时标记hasMore字段，前端根据该字段决定是否继续触发加载。

4.4 权限控制的两种实现：按钮级隐藏与后端校验

物业端和管理端共用一个系统时，权限控制从页面层到接口层要做两层。页面层是控制“看得到什么”——业主不显示派单按钮，物业不显示提交换按钮。接口层是控制“能调用什么”——即使有人在控制台手动调用管理端接口，后端也要拦截。页面层控制可以用一个简单的角色判断：

// 小程序端按钮显隐控制 const role = wx.getStorageSync('role'); // 'owner' 或 'property' // 报修单详情页 showApproveButton: role === 'owner' && order.status === 2, showAssignButton: role === 'property' && order.status === 0, showCancelButton: role === 'owner' && order.status === 0

后端校验则用中间件实现。我在后端定义了authMiddleware和roleMiddleware两个中间件，前者解析 token 拿用户身份，后者校验角色。这两个中间件的顺序不能换：先认证再鉴权，否则拿不到用户信息。写完这一段代码，论文里“系统安全设计”章节就有内容可写了——可以描述 token 校验流程、角色权限矩阵和接口防越权设计。

5. 联调与上线避坑：6 个真实翻车现场

下面是这几年做这类系统、带毕设时高频踩坑的集合。每一条都是实际发生过的问题，按现象 → 原因 → 解决三段来写，排查的时候可以当清单用。

5.1 真机预览白屏，开发者工具一切正常

现象：开发者工具模拟器里页面正常，扫码真机预览时首页白屏，控制台报app.js错误。

原因：最常见的是基础库版本不一致。开发者工具默认使用的是最新基础库，而真机上可能用的是微信客户端自带的旧基础库。某些新 API 在旧基础库上不存在，比如wx.chooseMedia在基础库 2.10.0 以下不可用，我用的wx.uploadFile的返回值结构在旧版本里也有差异。

解决：在app.json的libVersion字段里指定一个目标基础库版本，把这个版本写到项目的project.config.json中，并且真机预览时在调试器里查看基础库版本号。一般建议统一到 2.14.0 以上，这个版本覆盖到绝大多数 API 的稳定实现。

5.2 请求接口报“域名不合法”，但不是域名错了

现象：真机调试时wx.request请求局域网后端，报url not in domain list，但在开发者工具勾选了“不校验合法域名”后正常。

原因：微信对真机环境有强制域名校验，开发者工具的“不校验”选项只作用于开发者工具。个人开发者在没有备案域名时，这个问题无解——不是代码问题，是平台规则。

解决：三个方向任选。本地调试用“真机调试 + IP 直连”时在预览二维码弹出的页面上点“开发版需要打开调试模式”；要长期测试就必须配 HTTPS 域名并加到小程序后台的 request 合法域名列表。云开发的调用不受此限制，这就是很多人选云开发的原因。

5.3 云数据库数据“丢失”，列表里看不到别人的记录

现象：云开发环境里，上报修工单和公告数据后，换一个微信号登录，列表页面看不到数据，但云开发控制台里明明有记录。

原因：云数据库默认的权限设置是“仅创建者可读写”。在云开发的默认安全规则下，每个用户只能查到自己的创建的记录，这在单机调试时看不出来，因为调试用的就是创建者本人。

解决：在云开发控制台修改集合的安全规则。公开读、创建者可写的规则适合公告和报修列表场景：

{ "read": true, "create": true, "update": "doc._openid == auth.openid", "delete": "doc._openid == auth.openid" }

这条规则意味着登录用户都能读，但只能改自己的记录。物业端如果需要对所有工单进行派单操作，可以加一个自定义字段判断管理员身份，而不是直接放开写权限。安全规则是云开发踩坑大户，每写一个集合，先想清楚谁能读谁能写。

5.4 页面显示的时间比实际慢了 8 小时

现象：云函数或 Node 后端直接new Date()存入数据库，小程序端拿到后显示时间比北京时间慢了 8 小时。

原因：服务器或云函数的运行环境默认使用 UTC 时区，北京时间是 UTC+8。直接把时间戳塞给前端格式化时，没有做时区转换。

解决：后端统一存Date类型，前端渲染时不用字符串截取，而是用dayjs(createTime).format('YYYY-MM-DD HH:mm')指定时区：

const dayjs = require('dayjs'); // 存库时使用本地时间 const now = dayjs().add(8, 'hour').toDate(); // 前端如果拿到的是时间戳，展示时用 +8 时区 dayjs.tz(timestamp, 'Asia/Shanghai').format('YYYY-MM-DD HH:mm');

这两个做法任选其一，但要在项目里统一。最怕的是有的接口存 UTC，有的存北京时间，排查时完全靠猜。血泪经验：在工具类里写一个formatTime()的统一出口，所有时间显示都走这个函数，避免在页面里散落格式化逻辑。

5.5 用户第二次进入页面时，上次的筛选条件还在

现象：用户从报修列表筛选“待验收”后退出，再进入列表页，筛选条件还停留在“待验收”，但用户以为进入的是全部工单页面。

原因：小程序页面栈有缓存机制，页面onLoad只在首次创建时触发，切后台或返回上一页再进入时触发的可能是onShow。筛选条件是存在data里的，页面没有销毁，所以依然保留。

解决：区分初始化逻辑放onLoad还是onShow。筛选类页面的数据重置放在onShow里，页面创建时的初始化放在onLoad里，不要在onLoad里重置data，这样就能避免二次进入保留旧状态。

5.6 微信支付回调地址配置错误导致订单一直“待支付”

现象：模拟支付正常，接入真实微信支付（如果申请了商户号）后，支付成功但订单状态没有变为已支付，甚至回调日志完全空白。

原因：微信支付的成功回调是服务器异步通知到你在商户平台配置的notify_url，这个地址必须是公网可访问的 HTTPS 地址。本地开发环境收不到回调，回调逻辑没有打日志时看起来就是“没反应”。

解决：接入真实支付时，用内网穿透工具把后端notify_url暴露到公网测试。同时在后端回调接口里写日志，任何请求先打印请求体，再验签，再更新订单。回调接口不是普通接口，它接收的是微信服务器的 XML 或 JSON 数据，不能复用普通接口的鉴权中间件，不然微信的请求会被拒之门外。

6. 论文与答辩：让代码变成一篇能过盲审的毕设

6.1 论文框架直接对照工程结构来写

毕设论文的章节结构可以和你上面的工程结构一一对应，下面是一个经过验证的框架，直接照着填内容即可：

写论文最容易卡在第 2 章“现状调研”，这个章节你要换个口吻去写自己的系统：这个题目为什么需要“信息化”？传统物业管理的痛点是什么？可以在论文里找一个角落分析业主报修“打电话找不到人、没有流转记录、无法评价”这三个痛点，把它们变成你系统的功能亮点。

6.2 图与表的三条规范：统一风格、手画时序图、对齐截图

答辩老师翻论文第一眼看图，图的好坏直接影响评审印象。第一，所有图用同一个工具画，建议都用绘图软件，不要一部分用 Visio 风格、一部分用 PowerPoint 风格、一部分又是截图。第二，数据库 E-R 图必须自己画，不要用建表 SQL 直接截图，E-R 图体现的是设计能力。第三，系统实现章节放截图时，截图四周不要留白太多，统一裁到窗口内容区，保持清晰度。

论文里最容易被问到的图是“系统架构图”和“报修时序图”。时序图推荐这样画：业主在小程序端点击提交→请求到达后端→后端写入数据库→返回成功→小程序端提示提交成功→物业端收到新工单通知。这条链路就是 4.2 节代码的图形化表达，代码和图在论文里要呼应起来。

6.3 答辩高频问题先准备好答案

答辩问题都围绕“设计决策”和“边界漏洞”两个方向。把下面这些问题提前写好答案，现场就不会冷场：

• 为什么选微信小程序而不是 App？答：免安装、触达率高、开发成本低。
• 你如何防止业主越权查看别人的工单？答：后端接口按 openid 过滤数据，前端仅做展示控制，关键操作用中间件鉴权。
• 如果并发 1000 人同时报修怎么办？答：当前单机部署不支撑这个量级，优化方向是走云函数弹性扩缩容，这是论文中已考虑的扩展点。
• 你觉得自己系统最大的不足是什么？答：当前未接入真实微信支付，原因是个人主体无商户号，接口已预留，替换的时候只需改一个支付类型参数。

最后一个问题尤其重要。主动承认一个边界并说明解决办法，比被老师挑毛病更体面。不要答“没有不足”，这让答辩老师无话找话，局面不受控。

我的习惯是：论文和代码同步推进，代码每跑通一个模块，马上截图存到论文对应位置，等所有功能做完，论文已经有了 70% 的素材，剩下的时间专门打磨文字和格式。顺序反了就痛苦了——代码做完再补论文，相当于把开发过程重述一遍，很多当时没留意的细节都记不住，翻代码翻到怀疑人生。这个办法用在我带过的每个毕设项目上都管用，希望你也能用上，少走点弯路。希望帮到你。

本文还有配套的精品资源，点击获取