如果你正在做毕业设计或者课程实训，大概率会在 Spring Boot 和微信小程序这个组合周围打转。医疗类小程序是这几个方向里性价比比较高的选择：业务模型完整、前后端闭环清晰、又有明确的现实应用场景。这套基于 Spring Boot 医疗小程序的项目我前后参与梳理过三个版本，从最开始只有登录和列表展示，到后来补全了科室排班、预约挂号、问诊记录管理，慢慢踩出了一些真正值得记录的经验。这篇直接把从技术选型、核心链路、模块实现到上线发布、论文答辩的完整过程讲清楚，代码和讲解思路都能直接迁移到自己的项目里。

1. 项目定位：这个医疗小程序到底解决了什么问题

先搞清楚一件事：医疗小程序和常见的电商、新闻类小程序最大的区别在于业务是强状态型的。你不只是展示信息，而是要管理“排班—预约—就诊—记录”这一整条状态链。做项目之前不把这个链条理清楚，后面写代码会反复推倒重来。

1.1 系统角色与业务边界

这个项目里我最终确定了三类角色：患者、医生、管理员。患者通过小程序完成注册登录、浏览科室和医生、查看排班、提交预约、查看问诊记录；医生通常在小程序或管理端查看自己的排班和预约患者；管理员负责维护科室、医生、排班等基础数据，同时处理预约记录的核对与取消。

很多同学一开始会把角色做得特别复杂，比如加入药师、护士、收费员，结果后台权限模型越写越臃肿。我的建议是：毕设和课程项目优先保证主链路闭环，角色控制在三个以内，把预约和问诊这两条核心业务做透，比堆砌一堆用不上的角色要扎实得多。

1.2 核心功能范围与用户价值

从用户视角出发，这个小程序解决的是“去医院挂号排队时间太长”的问题。用户打开小程序后，可以先浏览科室列表，查看每个科室下有哪些医生，再根据医生的排班时间选择合适的时间段提交预约，到院后凭预约记录直接就诊。就诊结束后，医生可以填写简单的问诊记录，患者在小程序里随时查看。

从开发视角看，这套功能覆盖了一个完整业务系统该有的基础组件：用户认证（微信登录）、权限控制（JWT + 拦截器）、数据存储（MySQL）、缓存与并发控制（Redis）、接口文档（Swagger）。这些组件拿出来任何一个都能在面试或答辩时展开讲，所以这个选题不是简单的“玩具项目”，而是可以深挖的技术载体。

1.3 为什么医疗方向适合做毕设/实训

我参与过很多次项目评审，医疗类选题在答辩时的亮点在于需求分析好写、模块划分清晰、数据库设计有东西可讲。相比泛泛的“图书管理系统”或者“新闻发布系统”，医疗预约的业务规则更复杂：同一时间不能重复预约、医生排班需要动态维护、患者状态需要流转管理。这些规则本身天然就是论文里的“关键技术点”，不用额外编造。

2. 技术选型：Spring Boot + 微信小程序组合的取舍逻辑

技术选型这部分是论文第一章和答辩第一个问题的常客。很多同学只知道“别人都用这个”，却说不清楚为什么。下面把我实际选择这套技术栈的思考过程完整列出来。

2.1 为什么后端选择 Spring Boot

Spring Boot 的核心价值是“自动装配+约定优于配置”。传统 SSM 项目要手写大量 XML 配置，数据源、事务、扫描路径哪个环节出错都够折腾半天。Spring Boot 通过 starter 机制把常用场景的依赖打包好，引入一个 spring-boot-starter-web 就能快速把 Web 服务跑起来，这点在开发效率上是碾压级的。

版本选择上要格外小心。我最初使用 Spring Boot 3.2 搭配 JDK 17，结果发现一些老版本的第三方工具包没有适配，尤其是部分代码生成器和旧版 MyBatis 插件，折腾了很久才解决。后来稳定在 Spring Boot 2.7.x + JDK 8 的组合上，生态兼容性最好，网上资料也多，遇到问题几乎都能搜到现成答案。对项目型开发来说，稳定复现比版本追新更重要。

2.2 为什么前端选择微信小程序

微信小程序的核心优势是免安装、即用即走、微信内天然流量。从开发角度来说，小程序提供了一整套成熟的 API 和组件，一个熟悉 Vue 或 React 的开发者几天内就能上手。相比原生 App，小程序不需要处理安卓和 iOS 两套打包流程；相比 H5，小程序在登录态、支付能力、消息触达方面都有原生支持，体验更接近原生应用。

医疗场景还有一个现实原因：目标用户是普通患者，他们最熟悉的入口就是微信。一个小程序码贴在导诊台，扫码即用，这个交互路径比让用户去应用商店下载 App 或者输入网址要顺畅得多。

2.3 整体架构与技术栈清单

整个系统采用前后端分离架构，小程序端和后端通过 HTTP 接口通信。后端只负责业务逻辑和数据持久化，不关心前端页面渲染，这样小程序端、管理后台甚至后续要接一个公众号 H5 都可以复用同一套接口。

层	技术选型	说明
前端小程序	微信原生框架 + WeUI	不需要引入重型 UI 库，原生组件足够
后端框架	Spring Boot 2.7.x	稳定版本，兼容 JDK 8
ORM	MyBatis-Plus	简化单表 CRUD，分页查询好用
数据库	MySQL 8.0	存储业务数据
缓存与分布式锁	Redis	缓存科室列表、控制号源并发
认证授权	JWT + 拦截器	无状态会话管理
接口文档	Swagger（knife4j）	生成在线接口文档
部署	Nginx + 云服务器	部署后端和 HTTPS 证书

这里单独说一下为什么用 MyBatis-Plus。医疗系统里单表查询非常多，科室、医生、排班、预约基本都是常规增删改查，MyBatis-Plus 的 BaseMapper 直接提供了这些方法，省去大量手写 SQL。遇到多表关联或者复杂统计，再写 XML 里的自定义 SQL，两者结合很顺手。

2.4 为什么不选微服务架构

这一点需要和评审老师提前对齐思路。医疗小程序当前体量下完全不需要 Spring Cloud 那套微服务组件，一个单体应用把模块分层做好，部署简单、问题容易排查。我在答辩时的说法是：系统在 V1.0 阶段优先保证核心流程完整，模块内部做好高内聚低耦合，未来如果业务量增长，可以按科室、预约、用户等维度拆分为独立服务，这个渐进式演进路径是合理的。

3. 微信授权登录链路：从 code 到 openid 再到 JWT 的完整闭环

登录认证是小程序项目里最容易被想当然的模块，也是网上提问最多的模块之一。热搜里那条“小程序获取登录后的微信用户失败”十有八九就是 code 换 openid 环节出了问题。我把这条链路完整拆开讲。

3.1 微信小程序端的登录触发流程

小程序端通过 wx.login() 获取一个一次性凭证 code ，这个 code 有效期只有五分钟且只能用一次。拿到 code 后调用后端接口，由后端去微信服务器换取 openid 和 session_key 。这里的关键点在于： openid 是用户在当前小程序下的唯一标识，任何一个真实业务系统都应该把它作为用户主键，而不是让前端直接传一个用户名字符串。

Page({
  onLoad() {
    this.login();
  },
  async login() {
    const { code } = await wx.login();
    wx.request({
      url: 'https://api.example.com/api/auth/login',
      method: 'POST',
      data: { code },
      success: (res) => {
        const { token } = res.data.data;
        wx.setStorageSync('token', token);
      }
    });
  }
});

3.2 后端 code 换 openid 的接口实现

后端接收 code 后，调用微信官方接口 https://api.weixin.qq.com/sns/jscode2session ，传入 appid 、 secret 、 code 和 grant_type 。注意 secret 绝对不能暴露在小程序端，这就是为什么换 openid 的操作必须放在后端做。接口返回的 JSON 里包含 openid 、 session_key 和可选的 unionid ，其中 session_key 用于解密手机号等敏感信息，本项目没有用到，但也要在内存中处理，不要泄露到日志里。

@RestController
@RequestMapping("/api/auth")
public class AuthController {

    @Resource
    private AuthService authService;

    @PostMapping("/login")
    public R<String> login(@RequestBody LoginRequest request) {
        return R.ok(authService.wxLogin(request.getCode()));
    }
}

Service 层的核心逻辑是先判断 openid 对应的用户是否已经存在，存在则直接返回登录态，不存在则自动注册一个默认用户再返回登录态。这样用户整个使用过程中完全感知不到“注册”这个动作，体验最好。

public String wxLogin(String code) {
    String openid = wxService.getOpenidByCode(code);
    User user = userMapper.selectOne(
        new LambdaQueryWrapper<User>().eq(User::getOpenid, openid)
    );
    if (user == null) {
        user = new User();
        user.setOpenid(openid);
        user.setNickname("微信用户" + RandomUtil.randomNumbers(4));
        userMapper.insert(user);
    }
    return jwtUtil.generateToken(user.getId());
}

3.3 JWT 签发与拦截器校验

JWT 在这里充当的是“登录凭证”。用户登录成功后，后端签发一个包含 userId 和过期时间的 token 返回给小程序端。之后每次请求，小程序端在 header 里携带 Authorization: Bearer <token> ，后端通过拦截器解析 token、校验签名、取出 userId 放到 ThreadLocal 里供后续业务使用。

拦截器的配置有几点要注意。 /api/auth/login 和 Swagger 相关路径必须放行，否则会出现热搜里那条“springboot jwt 放开 swagger”的问题。放行配置建议直接写成字符串列表，不要用模糊的正则去匹配，减少误伤。

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

    @Resource
    private JwtInterceptor jwtInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(jwtInterceptor)
                .addPathPatterns("/api/**")
                .excludePathPatterns(
                    "/api/auth/login",
                    "/doc.html",
                    "/webjars/**",
                    "/v3/api-docs/**"
                );
    }
}

实际开发中我发现很多同学在登录这一步把 token 存到了 Redis 里，然后每次请求都去查一次 Redis 判断会话有效性。对于项目型系统来说这属于重复劳动，JWT 本身就可以做到无状态校验，除非要做强制下线功能，否则不建议引入 Redis 来做会话存储。Redis 在这里更合适的用途是缓存业务数据和控制并发。

3.4 登录失败常见的四种原因

我整理了调试过程中遇到最多的四类登录失败原因，对号入座能帮你省很多时间。

现象	原因	解决方式
返回 400 或 invalid code	code 被重复使用或已过期	确保每次登录都调用新的 wx.login()
---	---	---
返回 appid 与 secret 不匹配	小程序后台配置的 AppSecret 复制错误	重新生成 AppSecret，粘贴时注意空格
---	---	---
请求微信接口超时	后端服务器无法访问微信外网接口	检查服务器出网策略和防火墙配置
---	---	---
自定义登录态校验失败	JWT 密钥不统一或 token 过期	统一密钥配置，前端拦截 401 后重新登录

4. 核心业务模块设计：科室排班、预约记录与问诊流程

业务模块是整套系统的灵魂。前端界面做得再漂亮，如果预约流程混乱、数据库设计有硬伤，答辩时被追问两句就会露馅。这一章我会把数据表设计和几个核心接口的关键实现讲透。

4.1 数据库表设计：怎么用六张表撑起完整业务

数据库设计是论文里的重头戏。我最终保留了六张核心业务表： department （科室表）、 doctor （医生表）、 schedule （排班表）、 appointment （预约记录表）、 user （患者表）、 medical_record （问诊记录表）。

表名	关键字段	说明
department	id, name, intro	科室基础信息
doctor	id, department_id, name, title, intro	医生归属科室
schedule	id, doctor_id, schedule_date, period, total_count, remain_count	按时间段排班，记录剩余号源
appointment	id, user_id, doctor_id, schedule_id, appointment_date, status	预约记录，状态字段流转
user	id, openid, nickname, phone	小程序用户
medical_record	id, appointment_id, user_id, diagnosis, prescription	问诊结果与处方

这个设计的核心思路是把“排班”和“预约”分离。排班是医生在某天某个时间段放出的号源池，预约是对号源池的一次占用。这样的结构在后续做“取消预约后释放号源”时非常方便，直接对 remain_count 做加一操作即可。

4.2 号源并发控制：为什么不能只做前端校验

预约系统最典型的坑是“同一个时间段的最后一个号，被两个人同时约到”。单纯在前端做按钮置灰或者提交前查询剩余号数，都不能解决并发问题。后端必须把“扣减号源”和“生成预约记录”放在同一个事务里，并且用数据库层面的条件更新锁住号源。

UPDATE schedule 
SET remain_count = remain_count - 1 
WHERE id = #{scheduleId} AND remain_count > 0

这条 SQL 是预约接口的核心。它利用数据库的原子性，保证同一时刻只有一个请求能成功更新 remain_count 。如果受影响行数为 0，说明号源已经被抢完，直接返回“号源不足”的提示。在这个基础上，再加一个唯一索引约束，保证同一用户不能对同一排班重复预约，双保险。

@Transactional(rollbackFor = Exception.class)
public void createAppointment(AppointmentRequest request) {
    int rows = scheduleMapper.deductRemainCount(request.getScheduleId());
    if (rows == 0) {
        throw new BizException("当前时间段的号源已约满");
    }
    Appointment appointment = new Appointment();
    appointment.setUserId(request.getUserId());
    appointment.setDoctorId(request.getDoctorId());
    appointment.setScheduleId(request.getScheduleId());
    appointment.setAppointmentDate(request.getAppointmentDate());
    appointment.setStatus(0); // 0待就诊 1已完成 2已取消
    appointmentMapper.insert(appointment);
}

这里需要说明为什么有的项目用 Redis 分布式锁来控制号源，而我们没有。Redis 锁的方案适合系统有多个实例、流量较高的场景。单体应用直接依赖数据库的行锁和事务就可以保证数据一致性，实现更简单，也更容易在答辩时解释清楚。

4.3 预约状态机：字段取值要能被审稿人一眼看懂

预约记录的 status 字段我定义了三个状态：0 待就诊、1 已完成、2 已取消。状态之间的流转逻辑是：预约成功后处于待就诊状态，患者到院完成就诊后由医生或管理员更新为已完成；患者在就诊前可以取消预约，取消后状态变为已取消，同时释放号源。

这个状态机看起来简单，却是我在反复迭代中确定的。最初设计的时候还加了一个“待支付”状态，因为预约本身不涉及在线支付，凭空多出一个状态反而让流程变复杂。设计状态字段的原则是：每个状态都要对应一个真实的业务动作和技术行为，无意义的中间状态只会增加代码判断分支。

4.4 排班管理：医生排班数据从哪里来

排班数据是预约系统的基础。管理员在管理端选择医生、日期、时间段，设置该时间段的总号源数，系统初始化 total_count 和 remain_count 字段。小程序端查询排班时，直接返回剩余号源数，前端根据这个数值决定是否展示“约满”标签。

查询排班列表的接口需要注意一个细节： schedule_date 和 period 联合过滤。同一个医生同一天会有上午、下午、晚上多个时间段，前端需要一个 calendar 组件展示可预约日期，点击日期后拉取当天的排班。为了让前端少做一层组装，后端可以直接返回按日期分组的嵌套结构。

5. 小程序端开发：最容易翻车的五个细节

小程序端的坑和 PC Web 完全不同，很多问题不是逻辑错误，而是对小程序平台机制理解不够。这一节我挑五个实际开发中反复出现的细节展开。

5.1 app.json 页面注册与底部导航配置

小程序每个页面都必须先在 app.json 的 pages 数组里注册。底部导航通过 tabBar 配置，我设置了两个主页面：首页（科室浏览）和个人中心，中间再放一个“预约记录”页面。

{
  "pages": [
    "pages/index/index",
    "pages/doctor/doctor",
    "pages/schedule/schedule",
    "pages/appointment/appointment",
    "pages/mine/mine"
  ],
  "tabBar": {
    "list": [
      { "pagePath": "pages/index/index", "text": "首页" },
      { "pagePath": "pages/mine/mine", "text": "我的" }
    ]
  }
}

如果你的页面用了 tabBar 跳转，必须使用 wx.switchTab 而不是 wx.navigateTo ，否则控制台会报错，页面跳不过去。这个错误我在第一次联调时遇到了，印象非常深。

5.2 请求封装：统一处理 token 和 401

小程序原生的 wx.request 只是一个底层 API，直接使用会在每个页面里写大量重复代码。我封装了一个 request 工具函数，统一处理 baseUrl、请求头、token 注入和错误提示。

const request = (url, method = 'GET', data = {}) => {
  return new Promise((resolve, reject) => {
    const token = wx.getStorageSync('token');
    wx.request({
      url: 'https://api.example.com' + url,
      method,
      data,
      header: {
        'Content-Type': 'application/json',
        'Authorization': token ? 'Bearer ' + token : ''
      },
      success: (res) => {
        if (res.data.code === 401) {
          wx.removeStorageSync('token');
          wx.navigateTo({ url: '/pages/login/login' });
          reject(new Error('登录已过期'));
          return;
        }
        if (res.data.code === 200) {
          resolve(res.data.data);
        } else {
          wx.showToast({ title: res.data.msg, icon: 'none' });
          reject(new Error(res.data.msg));
        }
      },
      fail: (err) => reject(err)
    });
  });
};

如果不做集中处理，几十个页面里每个请求都要判断 401，分别跳转登录页，维护起来是灾难。

5.3 顶部导航栏与页面标题的适配

热搜里“微信小程序顶部导航栏高度”和“小程序头部标题”都是常见问题。导航栏高度在不同机型上不一致，iPhone 的刘海屏和小米等安卓机型有区别。适配方案是使用胶囊按钮的位置动态计算导航栏高度，而不是写死一个像素值。

头部标题我通常直接在页面的 navigationBarTitleText 里配置，比如“科室列表”“医生详情”“预约确认”。要注意的是，从 pages/index/index 跳到 pages/doctor/doctor 时标题会变化，这个变化是在 app.json 对应页面节点里配置的，也可以在当前页面的 onLoad 方法里用 wx.setNavigationBarTitle 动态修改。

5.4 页面跳转方式的选择：navigateTo、redirectTo、switchTab、H5 跳转

页面跳转是使用频率最高的操作，但很多人分不清这几个 API 的场景。 wx.navigateTo 用于页面栈压栈，可以返回； wx.redirectTo 关闭当前页再跳转，不能返回； wx.switchTab 只用于 tabBar 页面； wx.navigateBack 返回上一页。

项目里还遇到过一个需求：医疗百科页面需要跳转到外部 H5 内容。小程序跳 H5 有两个前提：第一，在微信公众平台配置业务域名；第二，使用 web-view 组件承载 H5 页面。这里容易踩坑的是业务域名需要下载校验文件放到服务端，而且域名必须 HTTPS。还有一个容易忽略的细节：个人主体的小程序不支持 web-view 组件，所以做小程序跳 H5 功能前要确认账号主体类型。

5.5 表单组件：单选框和多选一场景的取值坑

预约确认页需要患者选择就诊时间段，这里用到单选框组。微信小程序原生的 radio-group 和 radio 组件，取值方式是给 radio-group 绑定 bindchange 事件，事件对象里的 e.detail.value 就是选中的值。容易犯错的是把 value 写在了 radio 的文字内容里，而不是 value 属性上。

如果你用的是第三方 UI 库，比如 Vant Weapp 的 radio-group ，取值方式又会不一样。我的建议是项目里优先拥抱原生组件和一套 UI 库，不要混着用，否则光是表单取值就能耗费大量调试时间。

6. 调试、打包与部署：从开发者工具到正式环境的最后一公里

后端代码写完之后，真正的挑战才刚刚开始。小程序和普通 Web 项目不一样，它必须在微信的管制环境下运行，调试和部署都有独特的约束。

6.1 本地联调：为什么你的手机连不上后端

开发阶段最常用的联调方式是：小程序开发者工具勾选“不校验合法域名”，后端跑在本机的 8080 端口，小程序的 baseUrl 指向 http://localhost:8080 。但在真机预览时，手机上的小程序无法访问你电脑上的 localhost，这一问题困扰过非常多初学者。

解决方式有三种。第一种是让手机和电脑连同一个局域网，后端监听 0.0.0.0，baseUrl 改成电脑的局域网 IP；第二种是使用内网穿透工具，把自己的服务映射成一个公网 HTTPS 地址；第三种是直接部署到云服务器后再做联调。我建议开发阶段用第一种，速度快、零成本；等到做演示和真机测试时再切换到部署后的域名。

6.2 抓包与接口调试：怎么看小程序到底发了什么请求

小程序开发者工具自带的 Network 面板是最方便的抓包工具，切换到“调试器”的 Network 标签就能看到所有请求详情，包括请求头、参数和返回结果。需要排查登录问题时，重点看请求头里的 Authorization 字段是否携带正确，以及返回的 code 和数据内容。

真机上的抓包比开发者工具要复杂一些。Mac 上常用的方式是设置代理，让手机和电脑连同一局域网，电脑上开启代理抓包软件，手机在 WiFi 设置里配置 HTTP 代理，然后在抓包软件里安装根证书解密 HTTPS 流量。这个方法能解决大部分真机调试问题，但证书安装流程在不同手机上略有差异，实测时建议先用开发者工具排查，真机抓包作为兜底手段。

6.3 后端打包与服务器部署

后端打包很简单，Maven 执行 mvn clean package -DskipTests 即可，生成一个可执行的 jar 包。服务器上安装 JDK 8 和 MySQL，将 jar 包上传后通过 nohup java -jar medical-0.0.1.jar & 启动。

生产环境的接口必须走 HTTPS，原因有两个：第一，微信小程序正式环境要求所有请求域名必须是 HTTPS；第二，微信登录、手机号等敏感信息不能通过明文 HTTP 传输。我的实践是把 Nginx 作为反向代理，监听 443 端口，配置 SSL 证书，将 /api 路径转发到本地的 8080 端口。

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/nginx/cert/api.example.com.pem;
    ssl_certificate_key /etc/nginx/cert/api.example.com.key;

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

6.4 微信公众平台配置：域名、校验文件与发布流程

小程序正式上线前，需要在微信公众平台的“开发管理—开发设置—服务器域名”里配置 request 合法域名。这个配置只能填 HTTPS 域名，而且最多配置 20 个。配置完成后，把微信提供的校验文件下载下来，放到服务器的静态目录或项目 resources 目录里，保证 https://你的域名/校验文件名 能被访问到，才能通过校验。

发布流程是：开发者工具上传代码到微信后台，在公众平台提交审核，审核通过后点击发布。审核通常需要几个小时到一天，医疗类小程序需要注意类目问题——如果涉及在线问诊、处方药等医疗功能，可能需要提供相应资质。课程设计项目建议在答辩前留出两天的审核缓冲期，避免因为审核问题影响演示。

6.5 版本迭代与热更新

小程序有个好用的能力叫“热更新”，通过 wx.getUpdateManager 可以在用户打开小程序时静默下载新版本，下载完成后弹出提示引导用户重启。这个功能对线上项目意义重大，避免用户一直使用旧版本导致接口不兼容。

const updateManager = wx.getUpdateManager();
updateManager.onUpdateReady(function () {
  wx.showModal({
    title: '更新提示',
    content: '新版本已经准备好，是否重启应用？',
    success(res) {
      if (res.confirm) {
        updateManager.applyUpdate();
      }
    }
  });
});

7. 论文与答辩：把项目价值讲得和代码一样扎实

标题里提到了“精品论文+答辩PPT”，这部分我多说几句。代码能跑只是第一步，论文和答辩决定你的项目能不能拿到高分。很多同学代码写得很漂亮，但到了答辩环节讲不清设计思路，非常可惜。

7.1 论文结构怎么搭：从需求到测试的完整闭环

论文建议按这个顺序组织：绪论（背景与意义）、相关技术介绍、系统需求分析、系统设计、系统实现、系统测试、总结与展望。

大部分同学容易在“相关技术介绍”这一章写成一堆名词解释。我的建议是每个技术点都要关联到项目的实际使用场景。比如介绍 JWT 时，要说清楚它在项目里承担了用户登录状态验证的任务，和无状态服务是配套的；介绍 Redis 时，要说明它用于缓存科室列表和排班数据，降低数据库压力。这样写既避免了抄袭检测的风险，又让读者知道你是真的用过了。

7.2 图表比代码更直观：用例图、时序图、ER 图的画法

论文和 PPT 里，图表的力量远超文字。用例图表达角色和功能模块的关系，时序图表达登录流程或预约流程的调用顺序，ER 图表达数据库表之间的关联。这三张图是答辩现场最容易被老师放大查看的内容，务必画清楚。

画图工具有很多选择，Visio、ProcessOn、draw.io 都可以。我习惯用 ProcessOn，因为模板多、在线协作方便，而且导出图片清晰度高。画的时候不要贪多，一张图聚焦一个流程，比如“预约模块时序图”就只画用户、小程序、后端、数据库之间的交互，不要试图把所有功能画在一张图上。

7.3 答辩高频问题清单：提前准备这十问

答辩现场的问题其实是有规律可循的。我整理了十个月度高的问题，建议提前写好答案。

问题	回答思路
为什么选择 Spring Boot？	自动装配提高效率，生态成熟，适合快速构建单体应用
微信登录流程是怎样的？	前端 code → 后端换 openid → 签发 JWT → 后续请求携带
号源并发怎么解决？	事务 + 条件更新 SQL，保证数据库层面原子操作
JWT 和 Session 有什么区别？	JWT 无状态，服务端不存储会话，适合前后端分离
这个系统可以怎么扩展？	增加在线支付、消息推送、微服务拆分等方向
数据库为什么这样设计？	排班与预约分离，支持号源池复用，符合第三范式
测试用例怎么设计的？	功能测试覆盖主流程，接口测试覆盖参数异常场景
小程序端遇到过什么难点？	导航栏适配、token 集中处理、真机调试差异
项目有什么不足？	部分业务逻辑在人工操作，未来可自动化；数据库索引可以更细
系统的安全性如何？	SQL 预编译防注入、JWT 校验、HTTPS 加密传输

7.4 答辩演示顺序：先讲业务再讲技术

答辩演示一般只有十到十五分钟，顺序很有讲究。我的建议是先从用户视角走一遍完整流程：打开小程序、浏览科室、查看排班、提交预约、查看预约记录。这一遍走完，评审老师对项目就有了直观认识。

然后进入讲解环节，这时候一定要控制节奏，停留在核心模块上：登录认证和安全机制、预约接口的并发处理、数据库表的设计逻辑。不要试图把所有页面都点一遍，否则核心亮点反而被淹没。

7.5 源码与资料整理：给自己留一条退路

最后分享一条实操经验：项目开发过程中一定要建立清晰的目录结构，按“源码、数据库脚本、论文、答辩PPT、演示视频、README”分目录归档。我在帮别人梳理项目时就发现，很多人把代码、文档、截图混在一个文件夹里，答辩前光找资料就花了两小时。

数据库脚本尤其重要，除了建表语句，还要准备一些演示数据。排班表、科室表这些表如果没有数据，答辩演示时页面是空的，整个效果会大打折扣。我在项目的 sql 目录下放了初始化和增量脚本，克隆项目后导入就能直接跑起来，这才是真正“完整交付”的状态。

回到论文和答辩这部分，我参与过的每个项目都有各自的特殊性，但有一条是通用的：你对自己项目的理解深度，决定了评审老师对项目质量的判断。代码是你写的，数据表是你设计的，踩过的坑是你亲身经历的，把这些真实细节讲出来，比背诵任何理论都更有说服力。希望这篇梳理能帮你少走一些弯路，把精力真正花在把项目做实、做透上。