毕业设计必看：基于微信小程序的大学生体检预约系统全解析

每年毕业季，计算机专业的学生都在为毕设选题发愁。准备做系统开发的同学，十个里有八个绕不开“微信小程序”这个方向。但真上手才发现，小程序开发和传统Web开发完全是两码事——登录态怎么处理、预约冲突怎么避免、后台管理界面怎么搭、论文里的架构图怎么画，每一个环节都能卡住人。我自己带过不少毕业生，看过太多选题不错但落地拉胯的项目，所以今天拿一个比较典型的案例来拆：基于微信小程序的大学生体检预约系统。这套东西麻雀虽小五脏俱全，从前端交互到后端接口再到数据库设计，覆盖了一个完整毕设该有的所有核心模块。这篇文章会把整个项目从设计思路、技术选型、数据库建模、核心功能实现到论文写作要点全部过一遍，给正在做类似题目或者准备开题的同学一个可以复用的参考框架，也帮想快速上手小程序开发的人少走点弯路。

1. 项目整体设计与思路拆解

1.1 为什么选体检预约这个业务场景

毕设选题最忌讳的就是“大而空”。很多同学一上来就说“我要做一个校园综合服务平台”，结果功能列表写了两页纸，最后实现出来的每个模块都是半成品，答辩时被老师一问就露馅。体检预约这个场景的妙处在于：业务闭环清晰，角色边界明确，功能规模适中。

先看业务闭环。学生进入小程序、查看体检项目、选择时间段、提交预约、支付或在现场确认、查看报告，管理员在后台管理体检项目、维护预约时段、查看预约记录、处理取消申请。这个流程本身就是一个完整的业务链条，每一步都有明确的数据流转和状态变化，非常适合用来展示软件工程的核心能力。

再看角色划分。系统天然分为两端：小程序端面向学生用户，管理后台面向校医院或体检中心的工作人员。两端的数据是打通的，这就逼着你必须设计好权限体系和接口规范，而这两点恰好是答辩时老师最爱问的内容。

最后看功能规模。体检预约涉及到用户管理、项目管理、时段管理、预约管理、报告管理等多个模块，每个模块都不算复杂，但组合起来足够撑起一篇一万五千字以上的毕业论文。既有技术深度可挖掘（比如并发预约冲突处理），又有业务逻辑可描述（比如体检流程的状态流转），属于性价比非常高的选题类型。

1.2 小程序端和管理端的职责划分

这个项目最核心的设计决策，就是前后端分离 + 双端并行。

小程序端承担的是C端体验，需要做到“轻、快、简单”。学生打开小程序，第一眼看到的是体检项目列表和可预约的时间段，点进去能看项目详情（价格、时长、注意事项），选择合适的时间提交预约。个人中心里能看到我的预约、体检报告、取消预约入口。整个交互路径应该尽量短，一般控制在两到三级页面以内，因为体检预约属于低频操作，用户不会像刷短视频一样去研究你的界面，越直接越好。

管理端则是典型的B端后台，核心诉求是“清晰、高效、可操作”。体检项目管理（上下架、价格调整）、体检时段管理（生成每日号源、设置每个时段的最大预约数）、预约记录管理（查看、确认、取消）、学生信息管理（绑定学生信息、体检状态标记）、数据统计（每日预约人数、项目热度排名）。管理端我建议做成Web页面，用Vue或React都行。虽然也可以用小程序做管理端，但从用户体验和开发便捷性来说，Web后台永远是最优解。

这里有一个常见误区：很多同学把管理端做成小程序的第二个身份入口，学生在同一个小程序里切换“用户/管理员”身份。这种设计在小项目里好像省事，但实际上把两套完全不同的交互逻辑塞进了一个移动端容器里，页面层级会越做越深，状态管理会很痛苦。正确做法是分开：小程序只管C端学生操作，Web端管后台管理，两边通过同一套后端API通信。

1.3 项目的核心业务规则与状态流转

在设计数据库之前，必须先把业务规则理清楚，否则做到一半会被各种边界情况打乱节奏。体检预约系统最核心的业务规则有三条：

第一，一个学生在一个体检周期内只能预约一次。这里的“体检周期”可以理解为一个学年或者一个学期。这个规则意味着你需要在用户表里加一个体检状态字段，预约成功后状态变为“已预约”，体检完成后变为“已完成”，管理员有权重置状态开启新一轮体检周期。

第二，每个时段有人数上限，不能超卖。校医院的体检能力是有限的，比如上午8点到9点这个时段最多接待30人。这要求预约时段表里必须有“可预约数”和“已预约数”两个字段，每次预约请求提交时先检查已预约数是否小于可预约数，然后做更新操作。这里涉及到并发问题，后面我会专门讲怎么处理。

第三，取消预约有时间和次数限制。为了防止学生随意占用号源又不去，一般会限制只能在预约开始前24小时取消，并且每个学生每学期最多取消两次。超过限制后不允许再取消，只能联系管理员处理。

这三条规则确定之后，状态流转就清晰了。预约记录的状态一般是：待确认（刚提交）→ 已确认（管理员审核或系统自动确认）→ 已完成（体检结束）→ 已取消。再加上一个“爽约”状态（预约了没来且没取消）。整个状态机明确后，前后端开发可以并行推进，不用频繁沟通状态怎么传。

2. 技术选型与核心模块架构解析

2.1 技术栈选择：不追求新，追求稳

做毕设和做商业项目心态不一样，你的目标不是做出国内最大体检平台，而是在有限时间内完整交付，并且能用流畅的语言向老师解释每一层技术选型的理由。

小程序端没有悬念，原生微信小程序开发就够了。我知道现在有uni-app这类跨端框架很流行，但对于一个以毕设为目标的单体项目，原生小程序的学习曲线更平缓，调试工具更成熟，而且不存在框架层面的黑盒问题。万一代码出bug，你能直接在小程序开发者工具的Sources面板里定位到具体js文件，不会被框架编译环节干扰。如果你自己有Vue基础，用uni-app也不是不行，但答辩时最好能解释清楚“为什么跨端框架在本项目中是合理的”——解释不清楚反而会变成减分项。

后端我推荐用Spring Boot。原因有三：一是Java是绝大多数高校计算机专业的必修语言，答辩时老师对你的技术栈更熟悉；二是Spring Boot的生态太完善了，集成MyBatis Plus做数据库操作、集成Sa-Token或JWT做登录鉴权、集成Lombok减少样板代码，都是一行依赖的事；三是网上资料多，遇到问题搜得到解决方案，不会在环境配置上卡一整天。当然，如果你对Node.js更熟，用Express或Koa也完全没问题，关键是要在你自己的技术射程范围内。

数据库用MySQL，这个是标准答案。存体检项目、用户、预约记录、时段这些结构化数据，MySQL完全够用。存储体检报告里的图片或者PDF文件，建议直接存在服务器本地路径或者OSS对象存储里，数据库只存文件URL，不要用text字段存base64，否则数据库会越撑越大，查询效率直线下降。

2.2 数据库表设计与关键字段规划

这可能是整个项目里最值得花时间的地方。数据库表设计的好坏直接决定了后面接口写起来顺不顺手，也是论文里截图展示频次最高的部分。一个完整的体检预约系统，核心表大概有六张：

• student（学生表）：openid（微信登录唯一标识）、学号、姓名、性别、学院、班级、手机号、体检状态（0未预约/1已预约/2已完成）、创建时间。
• admin（管理员表）：账号、密码（加密存储）、姓名、角色。
• health_project（体检项目表）：项目名称、项目编码、描述、价格、所需时长（分钟）、状态（0下架/1上架）、排序权重。
• health_slot（体检时段表）：所属日期、开始时间、结束时间、总号源数、已预约数、状态（0关闭/1开放）。
• appointment（预约记录表）：学生ID、体检项目ID、时段ID、预约编号、状态（0待确认/1已确认/2已完成/3已取消/4爽约）、取消原因、创建时间、更新时间。
• health_report（体检报告表）：预约ID、学生ID、报告文件URL、身高、体重、血压等体检指标字段、总检结论、医生签名、发布时间。

其中几个关键设计点我需要展开讲。

openid字段是微信小程序登录的核心。每个微信用户在小程序里的openid是唯一的，相当于用户的身份证号。后端拿到前端传来的code后，调微信接口换回openid，再通过openid关联到student表。这里要注意，openid只能作为登录凭证，不能作为业务主键，因为它涉及微信平台策略，不具备业务属性。业务主键还是用自增id，openid单独建唯一索引。

预约编号建议用时间戳加随机数的组合生成，比如 202506011030 + 4位随机数，避免使用数据库自增id直接暴露预约业务量。这个编号会展示在学生端“我的预约”页面，也方便管理员在后台按编号快速检索。

health_slot表的“已预约数”字段是并发控制的关键。后面我在实现章节会详细讲减号源的操作时序，这里先记住一点：这个字段的更新必须是原子操作，不能在应用层先查后改。

2.3 小程序端页面结构与路由规划

小程序端的页面结构不复杂，但路径规划要合理，否则后面配置文件会乱。我的推荐结构是这样的：

• pages/index/index：首页，展示体检项目列表，支持按分类筛选，点击进入详情页。
• pages/project/detail：体检项目详情页，展示项目内容、价格、时长，底部按钮“立即预约”。
• pages/booking/select：预约选时间页，展示可预约的日期和时段，点击时段进入确认页。
• pages/booking/confirm：预约确认页，展示学生信息、项目信息、时段信息，确认后提交。
• pages/order/list：我的预约列表，展示当前学生的所有预约记录，按状态分类。
• pages/order/detail：预约详情页，展示预约状态流转、取消入口。
• pages/report/detail：体检报告页，展示报告指标和结论。
• pages/user/index：个人中心，展示学生身份信息、绑定学号入口、体检状态。

App.json里设置tabBar只需要三个tab：首页、预约、我的。“预约”这个tab可以直接指向pages/order/list，方便用户快速查看自己的预约进度。这样设计符合用户习惯：浏览项目、做预约、查记录是三个最高频操作，必须一级入口直达。

页面的规划建议在写代码之前就确定好，因为小程序要改页面路径关联的配置相对繁琐，如果做到一半想加一个入口页面，关联的跳转逻辑和参数都要跟着改，费时费力。

3. 核心功能实现：从登录到预约的完整链路

3.1 微信登录与用户身份绑定

微信小程序登录的逻辑很多文章写过，但踩坑的人依然很多。标准的登录流程是：

前端调用 wx.login() 获取临时code，把这个code传给后端；后端拿code加上小程序的appid和secret，请求微信的 jscode2session 接口，得到openid和session_key；后端拿着openid去student表查询用户是否存在，如果存在就生成一个自定义登录态token返回给前端，如果不存在则返回一个标记，引导前端跳转到“绑定学生信息”页面。

这里有个关键细节：小程序端的session_key不应该传给前端，也不应该存到数据库。session_key是用来解密用户手机号等敏感信息的密钥，一旦泄露可能导致用户数据被恶意解密。后端拿到session_key后只做一件事，就是用openid生成业务登录态，session_key直接丢弃，不落库。

Token的生成可以简单用JWT，把userId和角色信息放进payload里，设置7天有效期。小程序端把token存到storage里，每次request请求在header里带上 Authorization: Bearer token。后端用一个拦截器校验token的合法性，对需要登录态的接口做统一鉴权。这套方案虽然老套，但胜在简单、可解释、不易出错。

学号绑定的逻辑要注意：一个学生可能五年本科制里只有一次体检，但一个openid只能绑定一个学号。所以绑定接口要做幂等处理，同一学号不能被多个openid绑定。实现方式是在student表的学号字段加唯一索引，绑定操作在事务里执行，捕获到唯一索引冲突就返回“该学号已被绑定”的错误提示。

3.2 预约功能的实现与并发控制

预约是整个系统的核心业务，涉及多张表的联动更新，一定要用事务包起来。完整流程是这样的：

用户提交预约请求，参数包括学生ID、体检项目ID、时段ID。后端先校验学生当前体检状态是否为“未预约”，再校验该时段状态是否为“开放”，然后执行关键的号源扣减：

sql复制UPDATE health_slot 
SET booked_count = booked_count + 1 
WHERE id = #{slotId} 
AND status = 1 
AND booked_count < total_count

这条SQL的精髓在于用数据库层面的条件更新代替应用层的先查后改。如果直接先select出booked_count，判断小于total_count后执行update，在高并发情况下会产生超卖。因为两个请求可能同时读到同一个booked_count值，都判断可以预约，然后都执行加一，最终超出total_count。而上面的SQL把“判断+更新”合并成了一个原子操作，数据库在update时会加行锁，booked_count < total_count条件不满足的行不会被更新，受影响行数为0，就说明号源已满，直接返回“该时段已约满”即可。

号源扣减成功后，插入预约记录，状态为“待确认”，然后更新student表的体检状态为“已预约”。三个操作放在同一个事务里，任何一个失败都会回滚，不会出现号源扣了但预约记录没有的脏数据。

有人可能会问，既然系统自动做所有这些检查，为什么还需要“待确认”状态？这是为了留一个管理员人工干预的入口。比如某个学生填错了学号、选了不适合自己性别的体检项目，管理员可以在后台取消这笔预约并调整号源。自动确认固然省事，但人工兜底更稳妥。系统实现了管理员一键确认和自动确认两种模式，可以在后台配置，默认开启自动确认。

3.3 管理端Web页面的关键功能实现

管理端用Vue 3加Element Plus是最省事的组合。Element Plus的表格组件本身就支持分页、排序、筛选，配合el-dialog做编辑弹窗，基本上不用自己写复杂的样式逻辑。

管理端要实现的第一个核心功能是时段管理。校医院的体检时间通常是固定的，比如工作日每天上午8点到11点半。后台可以根据日期批量生成时段，比如某天生成8:00-8:30、8:30-9:00、9:00-9:30等六个时段，每个时段设置总号源数30人。生成逻辑很简单，前端传日期数组和时间区间，后端循环插入即可。这里要注意的是设置状态字段，如果某天医院临时停诊，管理员可以一键关闭整天的所有时段，学生端就看不到这些时段的预约入口了。

第二个核心功能是数据统计。虽然毕设不要求非常复杂的BI报表，但一个简单的统计页面会在答辩时非常加分。建议做这样几个统计：每日预约人数折线图、各体检项目预约占比饼图、各学院体检完成率排行。用ECharts封装好的组件，二三十行代码就能出一张图，但展示出来的效果会让论文的“系统测试”章节丰满不少。

第三个核心功能是预约管理。这是管理员最常用的页面。需要支持按日期、状态、学号、姓名多条件组合查询，支持对预约记录做“确认完成”操作，支持对爽约记录做标记。这里有一个细节：确认完成时要把完成时间写入预约记录，同时把student表的体检状态更新为“已完成”，如果配置了报告上传，可以在完成的同时引导管理员上传体检报告PDF。

3.4 体检报告模块与消息推送

体检报告是预约完成后闭环的最后一环。最省事的方案是管理员在后台把体检报告扫描件或电子版上传到OSS，系统记录文件URL，学生在小程序端“体检报告”页面查看。如果报告有结构化指标数据，可以在上传时做表单录入，存档成文本字段，学生端渲染成指标卡片的形式展示。

报告上传后应该通知学生。微信小程序有订阅消息功能，可以用来做状态通知。模板消息需要提前在微信公众平台申请，审核通过后会有一个模板ID。后端在用户完成预约时调用 subscribeMessage.send 接口发送通知。但这需要用户在小程序里主动授权订阅，而且一次性订阅模板只能发一次。

实际实现时要注意：订阅消息的授权时机要选对。不要在小程序首页弹窗让用户授权，那样用户大概率会拒绝。建议在提交预约成功的确认页上放一个“接收体检状态通知”的按钮，点击后触发授权，然后再调后端提交预约。这样授权意图明确，用户接受度会高很多。不过订阅消息这个功能在测试阶段经常面临模板申请审核不通过的问题，如果实在审不过也不影响系统主体功能，可以在论文的“未来展望”里提一句“已预留消息推送接口”。

4. 毕设论文写作与文档整理要点

4.1 论文结构规划：让老师顺着你的逻辑走

拿到题目后第一件事不是写代码，而是做论文框架。很多同学习惯先写代码后写论文，最后发现系统做了很多功能但论文里写不明白，甚至有些模块在论文中根本无法自圆其说。所以我的建议是：论文框架先出，系统开发对照着论文框架来。

标准的毕业论文结构可以分为七章：绪论（背景意义、国内外现状、研究内容）、相关技术介绍、系统需求分析、系统设计、系统实现、系统测试、总结与展望。这套结构是经过无数届毕业生验证过的，也符合答辩老师的阅读习惯，没有特殊原因不要擅自改。

需求分析章用用例图描述三类参与者的操作权限：学生、管理员、系统本身。每个用例配一个用例描述表，包括用例名、参与者、前置条件、基本事件流、异常事件流。这一部分是凑字数神器，也是体现你分析能力的地方，建议这里至少写3000字。

系统设计章要放总体架构图、功能模块图、数据库ER图、核心表结构设计、接口设计文档。第五章系统实现按功能模块走，每个模块截取关键页面截图和核心代码片段，配500字左右的实现说明。这里要克制一下，不要大段大段贴源码，老师看的是你的设计思路和工程能力，不是代码量。

4.2 配套文档如何写才能显得完整规范

毕设除了论文之外，一般还要交开题报告、中期检查表和任务书。这些文档里最容易拉开差距的是开题报告中的“可行性分析”和“进度安排”部分。

可行性分析分技术、经济、操作三个维度写。技术可行性说明你用了什么技术栈，为什么这些技术能完成目标，举出类似成功案例。经济可行性一般是“项目不涉及额外经济投入，开发环境使用开源软件”这种表述。操作可行性则说明系统的目标用户能否快速上手使用。

进度安排要写成甘特图形式，把整个毕设周期拆成六个阶段：文献调研、需求分析、系统设计、编码实现、集成测试、论文撰写与修改。每一阶段给一个明确的时间区间和交付物，这样答辩时老师问“你的时间安排是否合理”，你能拿出具体的排期表来佐证，印象分会好很多。

项目文档里还应该包含完整的API接口文档。不用特别复杂，用Postman导出JSON格式，或者用Swagger注解自动生成接口列表就行。接口文档的价值在系统联调和演示时体现得非常明显。

4.3 代码注释与项目结构规范的建议

代码规范这件事，平时写项目时不觉得重要，但答辩时老师现场翻你的代码工程目录，结构清晰不清晰一眼就能看出来。建议按Maven标准结构组织后端项目：controller、service、mapper、entity、common（统一返回结果、异常处理）、config（配置类）、vo/dto（视图对象和数据传输对象）。每个模块的类名保持可读性，比如 UserController、AppointmentServiceImpl，不要用缩写命名。

关键业务方法的注释一定要写。我要求的注释不是每行都写，而是在方法头写清楚“这个方法是做什么的、入参是什么、返回什么、有没有什么前置条件”。比如预约方法，注释应该能说明“此方法用于学生提交体检预约，执行流程包括校验学生状态、校验时段号源、扣减号源、新增预约记录、更新学生状态，整个流程在一个事务中执行”。这种注释在答辩时可以直接从IDE里截出来放论文里，非常加分。

前端小程序的代码目录也建议按照页面、组件、工具函数、请求封装、静态资源来组织。请求封装单独放一个request.js文件，统一处理baseURL、token注入、错误码拦截。这样写业务代码的时候全程只调api函数，不用关心底层请求细节。

5. 常见问题与排查技巧实录

5.1 微信开发者工具连不上后端接口

这是新手最容易碰到的问题，比业务代码本身的bug还让人崩溃。症状是前端请求发出去后，Network面板里显示请求失败或超时，报错信息一般是 request:fail。

原因通常是域名白名单限制。微信小程序在真机上只能请求配置了合法域名的接口，开发工具里虽然可以在“详情-本地设置”勾选“不校验合法域名”，但那个选项只对开发工具生效。真机调试时如果后端跑在局域网地址，比如192.168.x.x:8080，小程序请求会被拦截。

解决办法是：开发阶段用开发工具的“不校验合法域名”选项，把接口地址设为本地IP；后端开发时注意跨域问题，Spring Boot的Controller类加个 @CrossOrigin 注解，或者写一个CorsFilter统一处理跨域配置。如果是后端跑在云服务器上，需要在小程序后台配置request合法域名，域名必须要备案过的，且必须是HTTPS协议。这一点在毕设答辩演示时容易出状况，建议要么提前把后端部署到有备案域名的服务器，要么在答辩时直接用开发工具演示并且勾选不校验域名。

5.2 号源超卖问题复现与排查

并发场景在毕设答辩中经常被老师问到，但很多同学自己都没有真正测过。如果你想在演示时给老师展示这一点，可以用Postman或者Jmeter对预约接口做并发压测。比如某时段剩余号源为5，同时发起10个预约请求，正确结果是只有5个成功、5个返回“已约满”。

如果做出来效果不对，出现超卖现象，排查方向基本上是两个：一是取消预约后没恢复号源，属于业务逻辑bug；二是号源扣减没有做原子操作，比如在Java层用了先查再update的写法。把 booked_count = booked_count + 1 的条件更新写进SQL后，问题一般就能解决。

这里还要提一个容易忽略的边界情况：学生取消预约时，要把预约状态改为已取消，并且把对应时段的booked_count减一，同时把student表的体检状态改回“未预约”，这三个操作同样要在一个事务里完成。如果只更新了预约状态忘了恢复号源，过一段时间这个时段就会“明明没人约却显示满号”，非常隐蔽。

5.3 小程序真机预览正常但扫码体验版报错

开发工具里一切正常，但真机扫码打开体验版后白屏或者接口全部报错，这个问题我在好几个学生项目里都见过。原因几乎都是配置环境差异。

第一个坑是baseURL写死了localhost或者127.0.0.1。小程序在手机上是连不到你电脑的localhost的。如果后端在本地电脑跑，手机和电脑必须连同一个局域网，baseURL要改成电脑的局域网IP，比如192.168.1.101:8080。而且这个IP会随着路由器的DHCP分配变化，每次重启路由器可能都得改一遍，比较烦。

第二个坑是HTTPS证书。体验版和正式版要求所有request请求的URL必须是HTTPS，且TLS版本要符合要求。如果你只是想演示功能，有两个解决办法：一是把后端部署到线上平台，阿里云或腾讯云都有免费的学生机，申请一个免费SSL证书，把后端服务跑成HTTPS；二是在开发工具里扫码调试模式，也就是“真机调试2.0”，那个模式下手机和电脑建立了一个调试隧道，不校验域名和HTTPS，能临时应急。

5.4 微信订阅消息发送失败

订阅消息发送报错 43101 大概率是用户没有授权订阅；报错 40001 是access_token有问题，需要排查获取token的逻辑。43101 是毕设项目里出现频率最高的，因为开发阶段的测试用户可能之前点过“拒绝”授权。解决方法是把授权请求重新触发一次，在小程序后台清除用户授权记录。

还有一个细节：订阅消息的一次性模板授权只能支持一次发送，如果用户预约后想同时收到“预约成功”和“体检完成”两条通知，需要在授权时选择“总是保持以上选择”，并勾选对应模板，这在小程序端的相关API中有对应参数。但一次性订阅模板本身的设计就是让开发者在小程序后台的订阅消息配置里订阅消息的模板勾选对应的类型，实现时留意即可。

6. 远程调试与联调协作经验

6.1 环境统一：本地开发环境怎么配置最省心

做毕设的人多数是一个人同时干前端和后端的活，所以本地环境配置要点只有一个：代码库和数据库尽量都放在同一台机器上，不要一步涉及多台设备。

后端开发要用到Java开发环境、MySQL、Redis（如果用了）。建议把MySQL的端口固定为3306，数据库名统一叫 health_check_appointment，账号密码统一写在Spring Boot的application.yml里。前端小程序开发者工具直接打开项目目录，设置合法域名不校验就好。如果后端是本机跑，小程序端baseURL直接写 http://localhost:8080，开发工具模式不影响。

如果后续部署到云服务器，数据库导出sql文件，然后用命令行导入。注意字符集问题，MySQL数据库字符集统一用utf8mb4，否则存emoji表情（如果有人在小程序端个人简介里输入了）会报错。

6.2 远程调试的实际操作：后端部署到云服务器

毕设项目很多同学会主动部署到云服务器，因为答辩时用真机演示比拿电脑连模拟器效果要好得多。具体步骤我给一个可以照抄的清单：

服务器先装好Java运行环境、MySQL、Nginx。把后端的jar包通过scp或宝塔面板上传到服务器，命令参考：

bash复制scp health-appointment.jar root@你的服务器IP:/usr/local/app/

在服务器上启动jar包，用nohup在后台运行，日志输出到文件：

bash复制nohup java -jar /usr/local/app/health-appointment.jar > /usr/local/app/logs/app.log 2>&1 &

然后用Nginx做HTTPS反向代理，把443端口的请求转发到jar包的8080端口。这里要注意Nginx配置里设置 proxy_set_header X-Forwarded-For $remote_addr;，这样后端日志里能看到真实的用户IP，排查问题更直观。

小程序后台配置request合法域名时，域名不带端口号，Nginx监听443就把请求接入后端了。

这套流程配置一次大概一小时，配置完之后就再也不用担心“手机连不上电脑”的问题了。唯一需要留意的是云服务器带宽不要买太小，一般1M带宽够用，但体检报告如果上传多张高清图，加载会略慢，建议图片传给OSS，小程序端用懒加载，体验会好很多。

6.3 小程序开发者工具代码调试技巧

小程序端调试排查问题时，最实用的技巧就是在关键步骤加日志。

在app.js的onLaunch里打一个 console.log('小程序启动成功')，然后在每个页面的onLoad里打印页面接收的参数。出现问题时直接把手机或模拟器的Console面板截图发给后端同学，异常信息一目了然。

如果涉及表单提交，建议在提交接口的success回调里打印后端返回的完整数据，而不是只处理成功分支。因为很多bug的根源是后端返回了异常code，前端只处理了正常逻辑，忽略了错误提示，用户看到的表象是“点按钮没反应”，实际是接口报错了。

还有一个调试技巧是用 wx.vibrateShort 做预约成功后的震动反馈。这个小细节不会影响功能，但在答辩现场演示时，成功预约手机震一下，会给老师一种“这系统挺完整”的体验感受。

7. 给毕设同学的一些实际建议

最后说说我自己带毕设的一些体会。

第一，代码量不是越多越好，能跑通完整的业务链路比堆砌功能重要得多。我见过一个学生做一个商城系统，写了购物车、优惠券、秒杀、评论、楼层推荐，但下单流程本身有bug，老师演示时购买失败，场面一度很尴尬。体检预约系统做完基础功能且足够稳定，你的口碑就已经超过一半的同学了。新增功能应该放在核心流程稳定之后，比如消息推送、数据统计这些锦上添花的东西。

第二，数据库会说话。答辩时老师大概率会让你打开数据库看一眼表结构和几条数据。如果表设计清晰、字段命名规范、状态字段有注释，老师心里基本就给你过了。如果表里数据是空的，或者表名乱起比如test1、aaa这种，老师一定会觉得你系统是临时拼凑的。所以答辩前请务必造一点真实感强的测试数据：几个学生账号、一周的体检时段、几十条预约记录、几张报告文件，这些数据存在数据库里，演示时会自然许多。

第三，远程调试能力是隐藏加分项。如果答辩现场网络出问题了，你能迅速判断是域名问题、服务器问题还是代码问题，这种解决问题的能力本身就是毕业设计想考核的素养。

这个项目后续还可以往不少方向扩展，比如接入微信支付实现在线缴费、增加体检车预约功能、与校内信息门户统一身份认证对接，或者把预约系统从体检延伸到疫苗接种、心理测评等其他校园事务办理场景。数据和逻辑都是现成的，往前往后延伸都不是难事。做毕设最怕的是赶工，提前把架构搭好、表结构设计好，后面写代码的速度会超出你的预期。希望这套拆解能帮你在做体检预约小程序的时候少踩几个坑，做得顺利一些。