企业官网建设流程全解析

2023年到2024年之间，我接了不少以“毕业设计”为核心的微信小程序开发单子，上周刚交付掉一套标题叫“基于微信小程序实现传染病防控宣传管理系统”的项目，小程序前端、Spring Boot管理后台、数据库脚本、配套论文文档一套齐活。这类项目在课设、毕设、以及小型内部宣传工具里需求量一直很大，因为它的边界很清楚：不是做复杂业务系统，而是围绕“健康科普内容怎么下发、用户怎么学、数据怎么回收”这条线，把宣传的工作流管起来。今天这篇就把这套系统的设计逻辑、核心功能的实现细节、我在联调和真机调试阶段踩过的坑，以及拿到源码后从零跑通一套项目的完整路径都拆开讲清楚，给正在做同类型题目的同学一个可以直接参考的样板。

1. 为什么是微信小程序 + 宣传管理系统：从需求到选型的背后逻辑

1.1 这个系统到底解决什么问题

先理解项目名称里的关键词：传染病防控宣传管理系统。拆开看是两部分，前半部分是“传染病防控宣传”，这是业务场景，核心工作是健康科普、知识宣教、日常防护提醒等内容的组织与下发；后半部分是“管理系统”，说明它不是一个人简单发几篇文章就完事，而是需要一套内容管理、任务管理、用户触达、学习效果追踪的完整工具链。

传统宣传靠海报、横幅、公众号推文，最大的问题是触达不可控、效果难量化。你发了一篇科普文章，不知道多少人看了，不知道哪些人还没看，也不知道他们看完之后理解了多少。这套系统要回答的，其实就是三个运营层面的问题：第一，内容怎么发？第二，用户怎么学？第三，效果怎么评估？所有模块的设计都围绕这三件事展开，脱离这个主线去堆功能，系统就会变得臃肿且不好答辩。

我选小程序端作为用户触达入口，原因是微信小程序的传播成本在所有移动应用形态中几乎是最低的。扫码即用、无需下载安装、可以分享到群聊和朋友圈，内容的分发链条最短。用户端只承担“浏览、学习、答题、打卡”这些轻量动作，重的内容录入和统计分析全部放管理后台，这种前后端分离的逻辑天然契合宣传管理场景。

1.2 技术选型怎么定下来的

这套项目我采用了原生微信小程序作为前端，后端使用Spring Boot框架，数据库使用MySQL，管理后台用Vue加ElementUI实现。很多人会纠结一个问题：为什么不直接用uniapp？uniapp的优势是跨端，一套代码可以发小程序、App、H5，但问题是项目模板里如果带着原生的WXML和WXSS，转成的成本反而更高。原生小程序的API调用方式对新手更友好，wx.request、wx.login、wx.getPhoneNumber这些接口的文档大量集中在原生框架下，遇到问题搜资料也更容易找到答案。

后端选Spring Boot而不是Node.js或者Django，主要考虑了两点：一是这类系统需要和数据库、对象存储、短信接口等外部组件打交道，Spring Boot的生态成熟、示例代码多，尤其在学习阶段，遇到“控制层怎么写”“MyBatis分页怎么做”这类问题，几乎能搜到完整的案例；二是论文答辩环节，评委对技术栈的认可度很重要，Spring Boot加MySQL加Redis的组合是国内Web开发的主流，描述起来不会显得小众。

MySQL作为数据存储没有悬念，用户表、文章表、题目表、答题记录表，这个体量的数据用MySQL完全足够，而且课程设计和毕业设计的评定标准中，数据库设计的规范性是重要评分项，MySQL的表结构、主外键关系、索引设计都有很多现成范式可以参考。

1.3 功能边界：哪些做进系统，哪些坚决不做

此类宣传管理系统最容易翻车的地方在于需求蔓延。甲方或者指导老师容易觉得什么功能都可以加：加个聊天模块、加个支付功能、加个直播功能。我的处理原则是把系统功能控制在一个清晰闭环内：内容发布、任务指派、用户学习、答题测试、数据统计。这五个环节首尾相接，构成了宣传管理的最小有效单位。

具体来说，小程序端保留首页信息流、宣传任务列表、答题模块、打卡签到和个人中心五个一级模块。管理后台则提供内容管理、题目管理、任务管理、用户管理、数据看板五个页面。值得说明的是，这个系统不涉及支付、不做IM即时通信、不做视频上传，原因是这些功能与“宣传管理”的核心目标偏离，且会显著增加开发和维护成本。如果后续确实需要扩展，技术架构上也预留了足够的空间，不会推翻重来。

2. 功能拆解：小程序端和管理后台怎么分工协作

2.1 用户端：信息流、任务、答题、个人中心的职责分配

小程序端是普通用户接触到的全部内容，所以每个页面都要服务于“让用户愿意学、学得会、记得住”这个目标。首页承担的是信息聚合作用，顶部是公告栏和轮播图，运营人员可以配置多条宣传文章作为焦点图，下面是按分类切换的资讯列表，覆盖日常防护常识、季节性传染病科普、辟谣专题等内容。首页的细节在底部tab栏，我把它命名为“首页”“任务”“答题”“我的”四个入口，每个入口对应一个独立页面。

任务模块是这套系统的核心亮点。运营人员可以在后台发布不同类型的宣传任务，比如“阅读指定科普文章并达到停留时长”或者“观看一个健康科普视频”，用户可以点进任务列表查看待办事项，完成后获得积分。这个设计借鉴了游戏化运营的思路，把原本单向的“发通知”转变成用户有主动性的“做任务”，完成率会明显高于被动接收。

答题模块承担效果评估作用。它的逻辑很简单：运营人员在后台维护题库，配置单选题和多选题，前端在答题页面中展示题目、选项，用户提交后由后端进行判分并记录答题结果。成绩可以写入个人的学习档案，管理员在数据统计中能看到用户的正确率和参与次数，这些数据就是宣传效果量化的基础。

个人中心承载用户身份信息和学习记录，包括用户头像、昵称、手机号、累计积分、已答题数、已完成任务数、我的排名等。排名功能虽然实现成本不高，但对运营拉活跃度有实际价值，用户能看到自己在同社区或同单位的积分排名，形成轻度竞争关系，在一定程度上提升系统的打开率。

2.2 管理后台：内容与数据的统一调度台

管理后台面向的群体是健康科普运营人员或者系统管理员，它的设计原则是“最少的操作路径完成最多的工作”。内容管理模块维护文章和轮播图，支持富文本编辑和图片上传，发布状态有草稿、已发布、已下线三种。题目管理模块以表单形式维护题目内容，自动渲染选项列表，支持设置正确答案和解析内容。

任务管理模块负责创建宣传任务。创建任务时需要选择任务类型，绑定目标内容，设置有效期和积分奖励。任务发布后，用户可以立即在小程序端看到。数据看板是后台价值最直观的模块，它展示用户总数、新增用户趋势、答题参与人数、任务完成率等核心指标，图形化呈现运营状态。

这里有一个细节值得提：管理后台的账号系统和用户端是完全隔离的。管理者账号不通过小程序注册，而是在后台系统中由管理员直接创建，并且做了角色权限字段，避免普通用户的数据被越权修改。这种设计在论文中很好写，因为它是“权限设计”章节最天然的内容素材。

2.3 地图打卡与二维码场景的扩展设计

在这个版本里，我还实现了一个基于地理位置的方位知识点打卡扩展。运营人员可以在地图上配置宣传点位，比如一个社区健康宣传站、一个学校科普角，用户到达点位一定范围内后点击“签到打卡”即可获得积分奖励。这个功能的实现是典型的“位置服务加积分系统”组合，也是当前热搜词里频繁出现的“天地图 集成 微信小程序”的实际落点。

小程序内置的map组件可以直接展示经纬度点位并使用标记点标注，后端负责记录用户打卡时的经纬度坐标和打卡时间。为什么考虑集成天地图方案？主要原因是部分地区的地图服务对政务和公共卫生类场景有合规性要求，天地图作为公益性的地图服务，在资质和用途审查上比商业地图服务更简单。实际项目里既可以用微信原生地图组件间接调起地图服务，也可以用web-view标签内嵌天地图Web服务页，两种方案的取舍在论文的“系统实现”章节会是一个不错的写作扩展点。

3. 小程序端核心实现细节：导航栏、登录、答题与地图场景

3.1 自定义导航栏适配，别再写死高度了

微信小程序的“顶部导航栏高度”在我做过的几乎每个项目里都是第一道坎。默认情况下，页面顶部是系统自带的导航栏，标题由页面配置的navigationBarTitleText控制，此时你不需要关心高度计算。但只要想做出好看的自定义导航栏，比如背景渐变、自定义搜索框、带胶囊按钮的沉浸式头部，就必须把页面的navigationStyle设置为custom，关掉系统导航栏，完全用自己的组件渲染。

自定义之后，就涉及“小程序顶部导航栏高度”这个搜索量极大的问题。经常看到有人直接写死48像素或者64像素，然后拿真机一测就裂开，因为不同机型的状态栏高度和胶囊按钮位置完全不同。正确的做法是让程序自己算一遍：利用wx.getMenuButtonBoundingClientRect()获取右上角胶囊按钮的位置和尺寸，再结合wx.getWindowInfo()获取状态栏高度。

const menuButton = wx.getMenuButtonBoundingClientRect() const windowInfo = wx.getWindowInfo() // 导航栏总高度 = 状态栏高度 + 导航栏内容区高度 const navBarHeight = (menuButton.top - windowInfo.statusBarHeight) * 2 + menuButton.height const navBarTop = menuButton.top

这段代码里的逻辑是：menuButton.top减去statusBarHeight得到的是胶囊按钮距离状态栏底部的距离，把这个距离乘2加上胶囊按钮本身的高度，就是导航栏的总高度。实际项目里我会把这段计算写在一个公共的app.js工具函数里，页面在onLoad的时候调用一次，存到全局变量即可。这个方案实测覆盖了iPhone全面屏、Android各尺寸旗舰机等常见机型，高度误差控制在1像素以内。

3.2 登录与手机号授权的正确打开方式

登录模块是微信小程序项目的另一个高频踩坑点，尤其是“微信小程序登录获取手机号”这个热搜词背后，隐藏着大量的合入误解。先说结论：当前微信的登录体系包含两层数据，一层是用户身份标识（openid），另一层是手机号。openid通过wx.login()拿到code，再传给后端调用微信的code2Session接口换得；手机号则需要用户主动触发按钮回调。

新版手机号快速验证组件的接口已经全面调整，老式的“用户输入手机号”方案已经过时。现在前端只需要在页面上放置一个button，设置open-type="getPhoneNumber"，用户点击后可以在回调中拿到一个动态令牌code，把这个code传给后端，由后端调用微信提供的手机号换取接口，才能获得真实的手机号码。前端永远不会直接拿到手机号明文，这是微信出于隐私合规考虑的设计。

<button open-type="getPhoneNumber" bindgetphonenumber="onGetPhoneNumber">手机号快捷登录</button>

onGetPhoneNumber(e) { if (e.detail.code) { // 把 e.detail.code 传给后端换取手机号 wx.request({ url: API_BASE + '/auth/phone', method: 'POST', data: { code: e.detail.code }, success: (res) => { if (res.data.code === 0) { // 登录成功，跳转首页 } } }) } }

这里有个必须提醒的问题：手机号换取能力并不是默认开放的，它要求小程序已经完成企业主体认证，并且在后台开通相应接口权限。如果是个人主体的小程序，getPhoneNumber回调中拿到的code，后端在换取手机号时会报权限不足的错误。我在项目文档中特意标注了这一点：课程设计和毕业设计中如果无法申请到企业主体，可以把手机号绑定从“强制”降级为“可选”，用wx.login产生的openid作为用户标识即可完成全流程，论文里的实现方式对应着“基于微信OpenID的免注册登录机制”，照样能讲通。

3.3 答题模块：单选交互与计时器的实现细节

答题模块是小程序端交互逻辑最重的部分。题目的展示采用radio-group组件承载，一个题目对应一组单选按钮，用户点击选项将值写入当前题目的checked字段。选项渲染用wx:for循环，通过比较选项值和选中值来动态设置选中态。

<view wx:for="{{currentQuestion.options}}" wx:key="key" class="option-item"> <radio-group bindchange="onOptionChange"> <label class="option-label"> <radio value="{{item.key}}" checked="{{item.key === selectedValue}}" /> <text>{{item.label}}</text> </label> </radio-group> </view>

答题定时器是我在项目迭代中调整过的一个细节。第一版直接使用setInterval，每秒给剩余时间减1，测试时发现小程序切换到后台再切回来，倒计时就莫名其妙少了几秒。原因是小程序在后台时，定时器会被系统挂起或延迟执行。修复方案是用时间戳差值代替自增计数：在答题开始时记录startTime = Date.now()，每250毫秒读取一次当前时间，计算出实际经过的秒数，再换算成剩余时间展示。这样无论小程序在后台停留多久，回到页面的那一刻时间永远是准确的。

对于答题计时这个功能，还有一个严谨性上的考虑。问卷提交时，后端还需要根据试卷的结束时间校验试卷是否仍然有效，防止用户本地改时间数据作弊。前端的时间只是展示，真正的截止判定要在后端完成。

3.4 地图定位与二维码扫码场景的嵌入式实现

地图模块的核心实现并不复杂：后端维护科普点位的名称、经纬度和详情介绍，小程序端创建map组件，通过markers属性将点位渲染到地图上。用户点击标记点可以查看详情，点击“签到”按钮时，前端调用wx.getLocation获取当前经纬度，与点位坐标计算距离，如果实际距离小于设定阈值（比如200米）就允许签到。

小程序中实现地图定位时，需要注意一个权限顺序：app.json需要配置permission字段，在调用wx.getLocation前弹出授权说明；用户拒绝授权后需要有引导重新授权提示。这些细节看似琐碎，但在论文的“系统测试”章节可以用来编写测试用例，评委通常会关注这一类边界处理。

二维码扫码场景的应用方式是这样的：系统的运营人员可以在后台为单条宣传任务生成专属二维码，二维码携带着session参数。用户使用微信扫码后，小程序启动时会在onLoad(options)里收到query参数，根据参数直接跳转到对应的宣传任务详情页，省去了用户手动搜索的步骤。这个功能实现时用的是wxacode.getUnlimited接口，需要后端配合微信access_token的获取与缓存，调用频率有要求，不做好缓存会导致接口超限。

4. 后端接口设计与管理后台联调：从表结构到接口规范

4.1 统一返回体与接口路径规划

后端接口的设计对后续联调效率和论文书写都有直接影响。我采用的做法是定义一个统一返回结构Result<T>，包含code、message和data三个字段，所有接口统一返回这个结构，前端根据code字段判断业务成功或失败，而非依赖HTTP状态码。

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 0; result.message = "success"; result.data = data; return result; } }

接口路径规划遵循RESTful风格，同时在前面统一增加/api前缀。用户相关的接口有/api/auth/login、/api/user/info、/api/user/score；内容相关的有/api/article/list、/api/article/detail、/api/task/list、/api/task/complete；答题相关的有/api/exam/get、/api/exam/submit；后台管理接口独立在/api/admin/*下，通过拦截器校验Token鉴权，与用户端的匿名或半匿名访问区分开。

4.2 数据库表设计的关键关联关系

数据库部分的表结构设计是这个项目论文的重要章节。我在表设计时遵循了“按业务模块划分、避免过度冗余”的原则，核心表包括用户表、文章表、任务表、题目表、答题记录表和积分记录表，外加一张地理点位的扩展表。

用户表是业务的核心枢纽，字段包括主键id、微信openid、昵称、头像、手机号、总积分、注册时间等。文章表包含标题、封面图、内容、类型、阅读量、发布时间等字段。任务表通过target_id关联文章或视频内容，并通过task_type字段区分“阅读任务”和“视频任务”。答题记录表存储用户每次提交的答题明细和得分，这张表是运营数据统计的主要来源，通过一个detail字段用JSON格式存储用户的逐题作答情况，查询单次记录的详情不再需要join多张表。

积分体系是我单独开辟的一个章节。它的表设计思路是：积分记录表只负责流水记录，包含用户id、变化值、变动原因、关联业务ID和发生时间；用户总积分不在流水表中冗余存储，而是通过SUM聚合查询实时计算。虽然实时聚合对超大用户量有性能压力，但在本项目的规模下完全没有问题，而且保证了数据的绝对一致，论文里也很好解释。

4.3 联调阶段必须解决的那几个硬问题

前后端联调阶段，我几乎每次都要处理同样几个问题。第一个是开发环境的跨域问题。小程序端不通过浏览器发起请求，所以前端开发时不存在传统CORS跨域，但管理后台的Vue项目在本地开发时会遇到跨域，我在后端统一配置了跨域过滤器，允许开发环境下的各类请求头，线上环境则关闭该配置并依靠Nginx反向代理规避跨域风险。

第二个是微信开发者工具的合法域名校验。开发时勾选了“不校验合法域名”选项可以绕过限制，但到了真机预览和体验版阶段，小程序端的wx.request只能往后台配置的合法域名发起HTTPS请求，这是微信平台的硬性要求。因此交付文档里我单独写了一个章节，教用户如何在小程序管理后台设置request合法域名，否则用户无法在真机上正常调用数据接口。

第三个是时间格式的坑。前端传参使用ISO8601格式，后端MySQL的日期字段如果是datetime类型，在保存和读取时容易出现时区偏差问题。解决方案是在后端的统一JSON配置里设置时间格式化和时区参数，保证接口返回的时间与前端展示一致。

5. 高频问题排查纪录：这些坑我几乎每次都要处理一遍

5.1 导航栏在不同机型上的穿透和错位

自定义导航栏最容易出现的现象是：在开发者工具上看完美无缺，换成真机就出现“胶囊按钮和自定义标题重叠”“导航栏高度压缩导致内容顶到状态栏下面”等问题。最高效的排查方法是打印getMenuButtonBoundingClientRect的结果，对比iPhone与Android机型的数据差异，而不是盲目调整像素值。

另一个容易忽略的问题是web-view页面的导航栏适配。当小程序内嵌web-view时，网页顶部会与自定义导航栏区域发生冲突，需要专门在网页的body样式中预留导航栏高度的安全边距。这个坑在集成天地图Web版时尤为常见，我在项目文档里也做了保留地说明：如果点位地图采用页面跳转方式而非内嵌方式，可以完全绕开这个问题，从稳定性优先的角度我推荐这种实现。

5.2 手机号授权登录总是失败

手机号登录的失败案例主要有三类。第一类是点击按钮后没有回调触发，原因基本是button组件没有正确设置open-type属性，或者该方法没有绑定到bindgetphonenumber事件上。第二类是回调拿到了code但后端换取失败，排查方向是检查appid和secret是否正确，以及小程序后台是否已经开通服务接口权限。第三类是手机号按钮在部分Android真机不显示，常见原因是样式层级覆盖导致按钮透明，把按钮的层级调高即可解决。

这类问题我在调试过程中专门做了个排查表，放在项目的README里，可以帮助使用源码的用户快速定位问题。

5.3 答题计时器在小程序切后台后不准

这个问题上文已经提到，核心原因是小程序的定时器在后台会被系统冻结。除了时间戳差值法之外，还有个简单的替代方案：每次从后台切回前台时，通过onShow生命周期重新计算剩余时间，强制刷新。两种方案可以组合使用，效果更好。如果试卷逻辑允许超时后自动交卷，后端还需要在提交接口中再次校验试卷的截止时间，形成双重防护。

5.4 后端接口404和500问题

联调时如果前端请求后端接口出现404或者500，先别急着改前端代码。404的先排查请求路径是否拼错，Spring Boot的@RequestMapping路径是否带有多余的斜杠，尤其要注意Controller层的方法名和类名上是否各自加了一次/api前缀导致重复路径。500则优先查看后端控制台日志，最常见原因是MyBatis对应的Mapper XML文件里的SQL语句与数据库字段不匹配，比如数据库字段是create_time，实体类属性是createTime，在开启驼峰映射后会自动转换，但如果手动设置了resultMap，就需要确保字段映射完全正确。

这类问题对初学者来说是第一座大山，我通常建议在项目文档中先用最小可运行案例验证后端接口通了，再进入小程序端的页面联调，可以节省大量排查时间。

5.5 图片上传失败和包体超限

小程序端上传图片遇到“本地文件读取失败”或者“上传超时”，大部分情况下是上传接口的域名没有配置到HTTPS白名单，或者图片Base64编码后超过了请求体长度限制。更稳妥的做法是直接使用wx.uploadFile接口，配合后端对应的文件接收接口，将图片文件交给后端存储，前端只保存文件ID和展示地址。

包体大小超过2MB是另一个现象级问题。微信小程序的主包大小有严格限制，一般建议将答题模块、地图模块、个人信息等非首屏页面拆分为分包，使用subPackages配置。很多接手代码的人容易忽略这种分包思路，结果项目越加越大直到编译报错。分包结构在这个项目里天然适合，首页和任务是主包，答题和地图放入分包，实现一次配置一劳永逸。

6. 项目源码与论文文档：从解压到跑通再到答辩的完整路径

6.1 源码目录结构是怎么组织的

交付的源码通常按照“小程序端 + 服务端 + 数据库脚本 + 文档”四个部分组织，目录结构大致如下：

project-root/ ├── miniprogram/ # 微信小程序前端源码 │ ├── pages/ │ ├── components/ │ ├── utils/ │ └── app.js ├── server/ # Spring Boot后端源码 │ ├── src/ │ ├── pom.xml │ └── application.yml ├── sql/ # 数据库初始化脚本 │ └── init.sql └── docs/ # 论文与答辩文档 ├── 论文.docx └── 答辩PPT.pptx

使用源码的第一步是在微信开发者工具中导入miniprogram目录，填入自己的AppID或者使用测试号，然后修改utils/config.js里的接口地址为本机或服务器的后端地址。接着用Navicat或者命令行工具执行sql/init.sql脚本创建数据库和表。最后启动Spring Boot后端，确认接口能访问后，小程序端的登录和首页信息流就能流程跑通。

6.2 跑通全流程的详细步骤

我这里给一个可以直接照做的操作顺序。第一步，在MySQL中创建数据库health_edu，执行init.sql导入表结构和演示数据。第二步，使用IDE打开server后端工程，等待Maven依赖下载完成后，修改application.yml中的数据库用户名密码，以及微信小程序的appid与secret配置。第三步，启动后端，访问http://localhost:8080/api/article/list，如果返回JSON数据就说明后端就绪。第四步，使用微信开发者工具导入miniprogram目录，在app.js中修改配置项，将基础地址指向http://localhost:8080（开发环境勾选不校验合法域名）。第五步，编译运行，先体验一遍登录、文章浏览、完成任务和答题流程，再切到管理后台创建题目和任务进行数据联动。

有一点要特别提醒：微信开发者工具的模拟器与后端交互是走本地网络的，如果后端跑在虚拟机或者远程服务器，要将接口地址改为服务器对应的局域网IP或公网地址，同时注意后端是否监听了0.0.0.0。

6.3 论文怎么写才能和源码对得上

论文与代码的一致性是通过评审和答辩的关键，项目名称里的“论文说明”指的正是这一点。论文目录建议按经典顺序安排：第一章绪论，写研究背景、国内外现状、研究内容与意义；第二章相关技术介绍，介绍微信小程序、Spring Boot、MySQL、Vue等；第三章系统分析，细化用户角色、业务流程、功能需求和可行性分析；第四章系统设计，给出总体架构图、功能模块图、数据库E-R图与表结构；第五章系统实现，按页面截图加核心代码片段逐模块描述；第六章系统测试，列测试用例和结论。

写论文时最容易出现的问题是“代码实现了A但论文写了B”，或者论文中的截图与源码版本不一致。我的建议是让论文的第五章只挑选核心功能（登录、文章发布、任务完成、答题提交、数据统计）来写，每个功能配一两段实现说明和一个关键代码片段，再配一张页面运行截图。技术路线在描述时保持和源码一致，比如前端用的是原生小程序框架就写原生，不要为了显得高级而写成uniapp，答辩现场会被问穿的。一个安全的信息：如果你准备参考这套源码交毕设，至少把前端页面文字、后端包名、数据库表名前缀和论文里的系统名称做一次统一替换，再通读全文核实上下文，这是一个负责任的接手动作。源码是辅助学习的工具，真正的价值是你能把系统的每个模块讲清楚。

我的几点个人体会

做这类“源码加论文”的项目做多了，我最大的体会是：真正能顺利通过评审的，往往不是技术最花哨的方案，而是逻辑最自洽、文档和代码对照最清晰、功能闭环最完整的作品。传染病防控宣传管理系统这类项目的难点从来不在某个孤立的技术点，而是如何把“内容下发—用户学习—效果评估”这条链路贯穿起来。最后再分享一个实用建议：接手任何源码项目后，动手改代码前先做一次全流程手工测试，记录下每一处需要修改的地方，这个过程会让你在写论文和答辩时更有底气，因为你知道系统里每一个功能是怎么转起来的。