SpringBoot医疗挂号推荐系统：从架构设计到推荐算法落地

1. 项目整体设计与选型思路

1.1 为什么毕业设计选它：SpringBoot医疗挂号推荐系统到底解决什么问题

每年到了毕业设计开题季，我身边总有学弟学妹来问：做什么题目既不容易翻车，又能体现工作量？我的答案里大概率会出现“基于SpringBoot的医疗挂号推荐系统”。这个题目听起来不浮夸，但实际做下来你会发现，它几乎涵盖了Java后端开发的所有核心知识点：SpringBoot框架、MyBatis持久层、MySQL表关系设计、Redis缓存、推荐算法、前后端联调、部署上线。

先聊聊现实场景。去过大医院的人都懂，挂号这件事看起来简单，实际体验却很差。你打开挂号App，面对几十个科室、上百个医生，压根不知道挂哪个科。头疼脑热该挂内科还是神经内科？咳嗽一周是呼吸科还是耳鼻喉？就算查到了科室，哪个医生擅长看你这类型的病？出诊时间是几点？这些信息散落在各个页面里，用户要反复切换、对比、筛选，耗费大量时间。而另一边，医院的压力也很大，热门科室人满为患，冷门科室门可罗雀，医生资源分配极度不均衡。

这个系统的核心价值，就是用推荐算法把“用户主动找医生”变成“系统帮用户匹配医生”。系统收集用户的症状描述、历史挂号记录、浏览行为，结合医生的擅长领域、职称、好评率、出诊时段，计算出一个匹配度分数，把最合适的医生排在前面。用户少花时间，医院分流压力，这个切入点特别适合拿去写毕业设计的背景和意义，评审老师一听就知道你理解业务，不是空架子。

再来说技术选型。SpringBoot是目前Java后端最主流的框架，没有之一。配置简洁、生态成熟、社区资料多，遇到问题一搜就有答案，这对毕设党来说太重要了。搭配MyBatis操作数据库，Redis做热门科室和推荐结果的缓存，前端用Vue或Thymeleaf，整个技术栈都是企业里真实在用的。做完这个项目，你写在简历上的每一行技术栈都不是虚的，面试官问起来你也真的答得上。

1.2 系统功能全景图：给用户什么，给管理员什么

做毕业设计最容易犯的错，就是一上来就写代码，写到一半发现功能缺胳膊少腿，又回头补需求文档。我建议你先画一张功能脑图，把角色、功能、边界理清楚再动手。这个系统的用户角色很清晰：普通用户、医生、管理员。

先看普通用户端。用户进入系统后，第一件事是注册登录。登录之后可以维护个人信息，包括常见症状、历史病史、过敏药物，这些信息后面都会成为推荐算法的输入特征。接着是核心的挂号流程：用户输入症状关键词，比如“头痛发热”，系统返回推荐科室列表，每个科室后面附带匹配度和推荐理由；用户点击科室后，进入医生列表页，系统按照匹配度、好评率、出诊时间综合排序；选好医生后，看到一周内的出诊排班表，选择空闲时段，提交挂号订单。挂号成功后可以在个人中心看到订单状态，如果临时有事可以取消挂号，爽约次数多了会有限制。

再来看医生端。医生登录后能看到自己的出诊排班表，可以手动设置停诊时间。患者挂号后，医生可以在接诊列表里查看患者的基本信息和症状描述，提前了解病情。接诊结束后，医生可以对这次就诊做简单的备注，这部分数据会积累下来，成为推荐系统的反馈信号。

管理员端承担系统运维的核心职责。管理员管理科室信息、医生账号、出诊排班，审核用户的异常行为，查看系统统计数据，比如各科室挂号量、医生接诊量、用户增长趋势。这些统计图表用ECharts渲染，前端展示效果很好，答辩的时候加不少分。

这里要额外提一句：推荐模块是系统的亮点，也是技术难点。如果你只做一个普通的挂号系统，没有任何智能化的东西，那和其他人的题目没什么区别。但加上推荐算法之后，系统的层次立刻不一样了。后面我会单独用一节来讲推荐算法怎么落地。

1.3 技术栈与版本选型避坑指南

SpringBoot的版本选择，我的建议是别追最新版。很多毕业设计在最后部署阶段翻车，罪魁祸首就是版本不兼容。我用的是SpringBoot 2.7.x，这个版本非常成熟稳定，网上资料最多，遇到问题搜解决方案最快。Spring Boot 3.x虽然性能更好，但它底层是Jakarta EE命名空间，很多老教程里的代码直接复制过来会报错，对新手不友好。

配套的组件版本我列一个表参考：

有些同学觉得用最新版显得自己跟得上技术潮流，但毕业设计的核心目标是稳妥地跑起来、讲清楚、顺利答辩。技术选型追求的是“够用、稳定、会讲”，不是“最新、最炫”。举个实际例子，SpringBoot 3.0之后必须用 jakarta.servlet 取代 javax.servlet，很多老代码里的 import javax.servlet.* 直接编译失败，新手排查这个纯属浪费时间。

还有一个容易忽略的点：开发环境和生产环境的配置分离。你在本地用 application-dev.yml，部署到服务器用 application-prod.yml，通过启动参数 spring.profiles.active=dev 切换。这样本地调试的日志级别、数据库连接、Redis地址，和服务器上的配置互不干扰。我见过很多同学把本地的数据库密码直接写在配置里打包上线，这是最低级的错误，务必避免。

2. 数据库设计：推荐系统的数据地基

2.1 核心表结构拆解与关系梳理

整个系统的数据表大概有十张左右，核心的六张我建议你先设计好，其他的都是围绕它们打辅助。第一张是用户表 user，字段包括用户ID、手机号、密码（加密存储）、姓名、年龄、性别、既往病史、过敏史、创建时间。密码加密用什么？推荐BCrypt，SpringSecurity自带支持，不要用MD5，MD5现在已经不安全了。

第二张是科室表 department，字段包括科室ID、科室名称、科室介绍、科室位置、适用症状关键词。这个 symptom_keywords 字段非常关键，它是基于内容的推荐算法的匹配基础。比如“呼吸内科”的适用症状可以是“咳嗽,咳痰,发热,气喘,胸闷”，用逗号分隔存储，查询时用模糊匹配。第三张是医生表 doctor，字段包括医生ID、姓名、职称（主任医师/副主任医师/主治医师）、擅长领域、科室外键、好评率、接诊量、个人简介。

第四张是排班表 schedule，字段包括排班ID、医生外键、出诊日期、出诊时间段（上午/下午/晚间）、剩余号源、总号源。这张表的更新频率最高，用户挂一个号就要扣一个号源，所以要用乐观锁控制并发，防止两个用户同时抢到最后一个号。关于并发控制我后面细说，这里先记住一个原则：扣减号源必须保证原子性。

第五张是挂号订单表 appointment，字段包括订单ID、用户外键、医生外键、排班外键、就诊序号、状态（待就诊/已完成/已取消/爽约）、创建时间、取消时间。第六张是行为记录表 behavior_log，这张表是推荐算法的数据来源，字段包括日志ID、用户外键、医生外键、行为类型（浏览/点击/挂号/收藏）、行为时间。

2.2 冷启动阶段的数据填充与模拟

推荐系统最怕的就是冷启动，用户刚注册没有历史行为，系统拿什么推荐？这时候就要靠用户注册时填写的症状标签和科室的症状关键词做匹配。举个具体场景：新用户注册时填写了“我有过敏性鼻炎，经常打喷嚏流鼻涕”，系统从中抽取关键词“喷嚏”“流鼻涕”，和科室表的 symptom_keywords 比对，“耳鼻喉科”的适用症状正好包含“喷嚏,流鼻涕”，于是系统就把耳鼻喉科和该科室下擅长过敏性鼻炎的医生推荐给用户。

光有规则还不够，为了体现推荐效果，我建议做一套数据模拟脚本，生成一批合理的用户行为数据。脚本可以生成500个模拟用户，每个用户随机选择3到5个科室浏览过，对其中1到2个医生点击了详情页，最终挂了一次号。这些行为写入 behavior_log 表，协同过滤算法就有了计算基础。很多同学问模拟数据算不算作弊，我的看法是：毕业设计重在展示系统能力和实现思路，合理的模拟数据是为了让算法效果可见，这在项目文档中如实说明即可。

2.3 MyBatis关联查询的几种写法和区别

数据库操作层用MyBatis，核心PO类包括实体类、Mapper接口、XML映射文件。很多新手困惑的是：一个查询到底是写在单表Mapper里，还是写联表查询？我的建议是：列表页查询用联表查询，详情页查询用单表查询加二次组装。

拿“推荐医生列表”这个场景举例。前端需要展示医生姓名、职称、科室名称、好评率、剩余号源，这些字段分布在 doctor 表和 schedule 表里，用联表查询一次取出最方便。SQL大致长这样：

sql复制SELECT d.doctor_id, d.doctor_name, d.title, d.praise_rate, dep.department_name, s.schedule_id, s.remaining
FROM doctor d
LEFT JOIN department dep ON d.department_id = dep.department_id
LEFT JOIN schedule s ON d.doctor_id = s.doctor_id
WHERE d.department_id = #{departmentId}
AND s.off_date = #{date}
ORDER BY d.praise_rate DESC

联表查询的好处是减少网络次数、代码写起来直观，但要注意别滥用，尤其是多张表嵌套子查询的时候，性能会明显下降。毕设阶段数据量不大，基本上不用考虑极端优化，只要不写 SELECT * 这种坏习惯就好。

3. 推荐算法的设计与落地实现

3.1 基于内容的推荐：先用症状匹配科室

推荐算法是整个系统的灵魂，但很多人一听“算法”两个字就头大，觉得必须会数学公式才能做。我实话告诉你：毕业设计吃透两种基础推荐策略，组合起来用，就完全够用了。

第一种是基于内容的推荐（Content-based Filtering）。它的核心思想是：根据物品的属性，找和用户需求匹配的物品。在这个系统里，物品是医生和科室，属性是“擅长领域”和“适用症状关键词”，用户需求是“症状描述”和“历史病史”。

实现步骤我拆细一点。第一步，用户输入症状文本，做分词处理。Java生态里可以用HanLP或者简单的字符串分割。因为医疗场景的症状词相对固定，比如“头痛”“发热”“腹泻”“失眠”，我建议维护一个标准症状词库，用户输入后用包含匹配去症状库里捞。第二步，把捞到的症状词和科室表的 symptom_keywords 做交集计算，交集越多匹配度越高。第三步，按匹配度排序，如果匹配度最高的科室只有一个，就把这个科室排第一；如果有多个，可以按科室的日均挂号量做二次排序，把热度高的排前面。

举个具体例子，用户输入“咳嗽三天，伴有发热”。标准症状词库命中“咳嗽”“发热”两个词。“呼吸内科”的适用症状是“咳嗽,咳痰,发热,气喘”，命中两个，匹配度2/4 = 0.5。“普通内科”的适用症状是“发热,腹泻,腹痛,恶心”，只命中一个，匹配度0.25。此时呼吸内科排第一，推荐理由写“根据您的症状，呼吸内科匹配度最高”。推荐理由这个细节很重要，很多系统只给结果不给理由，用户不知道为什么推荐这个科，体验很差，答辩时老师也容易追问。

3.2 协同过滤：利用相似用户的行为做医生推荐

第二种是协同过滤（Collaborative Filtering），核心思路是：找和你相似的用户，看他们喜欢什么医生，把那些医生推荐给你。这个算法不需要知道症状，只需要用户行为数据，正好用上之前的 behavior_log 表。

基于用户的协同过滤实现逻辑是这样的。第一步，构建“用户—医生”评分矩阵，用户对医生的评分怎么算？没有显式评分，就用行为加权：浏览算1分，点击详情算2分，挂号算5分，取消挂号扣1分。第二步，计算用户之间的相似度，用余弦相似度公式。第三步，找到和目标用户最相似的K个用户，把这K个用户挂号过的医生汇总，按总权重排序，去掉目标用户已经挂过的，取前N个推荐。

代码不复杂，核心就三块：查行为数据、算相似度、生成推荐列表。给你看一下相似度计算的精简版实现思路：

java复制public double cosineSimilarity(Map<Long, Integer> user1Behaviors, Map<Long, Integer> user2Behaviors) {
    Set<Long> commonItems = new HashSet<>(user1Behaviors.keySet());
    commonItems.retainAll(user2Behaviors.keySet());
    if (commonItems.isEmpty()) {
        return 0.0;
    }
    double dotProduct = 0.0;
    double norm1 = 0.0;
    double norm2 = 0.0;
    for (Long doctorId : user1Behaviors.keySet()) {
        norm1 += Math.pow(user1Behaviors.get(doctorId), 2);
    }
    for (Long doctorId : user2Behaviors.keySet()) {
        norm2 += Math.pow(user2Behaviors.get(doctorId), 2);
    }
    for (Long doctorId : commonItems) {
        dotProduct += user1Behaviors.get(doctorId) * user2Behaviors.get(doctorId);
    }
    if (norm1 == 0.0 || norm2 == 0.0) {
        return 0.0;
    }
    return dotProduct / (Math.sqrt(norm1) * Math.sqrt(norm2));
}

这段逻辑里有个关键点：如果两个用户行为交集为空，相似度直接是0。所以前期数据模拟脚本一定要保证每个用户有足够的行为记录，不然协同过滤跑出来全是不相关的结果。

3.3 混合推荐策略：按场景动态切换推荐来源

只靠单一算法，场景覆盖不够。用户第一次来、行为数据很少的时候，协同过滤效果很差，这时候靠内容匹配兜底；用户用了一段时间、行为数据多了之后，协同过滤能发现内容匹配发现不了的弱关系。所以我的策略是：一个小型的混合推荐引擎。

怎么混合？我给每种推荐算法算一个置信度分数。用户注册时间小于7天或者行为日志少于5条，内容推荐权重给0.7，协同过滤给0.3。行为日志多起来了，协同过滤权重上调到0.7，内容推荐降到0.3。最终推荐分数 = 内容匹配分 × 权重1 + 协同过滤分 × 权重2。排序时按混合分数降序。

还有一个细节值得做：推荐结果的解释性。系统在推荐医生卡片上展示一行小字：“因为您最近浏览过三甲医院的呼吸内科王医生，为您推荐同科室的张医生”或者“和您有相似挂号习惯的用户也关注了这位医生”。这种解释能显著提升用户对推荐的信任感，答辩的时候也是亮点。实现上就是给每个推荐来源定义一个解释模板，在返回推荐结果时把模板填充进推荐理由字段。

3.4 Redis缓存推荐结果

推荐算法涉及查表、遍历、计算，如果用户每次刷新页面都实时算一遍，数据库压力大、响应速度也慢。我的做法是：把推荐结果缓存到Redis，设置合理的过期时间。

什么时候缓存、什么时候更新？我设的规则是：用户刷新推荐页时，先从Redis查询该用户的推荐列表KEY，比如 recommend:user:{userId}，如果存在直接返回；如果不存在，执行推荐算法，把结果存进Redis，有效期设为30分钟。为什么是30分钟？太短了缓存没意义，太长了用户的挂号行为不能及时反映到推荐里。到这一步，系统的技术深度已经有了：SpringBoot + MyBatis + Redis + 推荐算法，一套组合拳打完，答辩的深度分基本稳了。

4. 核心业务实现与难点攻克

4.1 挂号并发控制：怎么避免最后一个号被抢超

挂号系统业务的硬骨头就是并发。想象一个场景：某个专家号源只剩最后1个，两个用户同时点击“确认挂号”，如果没有并发控制，两个人大概率都会挂号成功，但号源只有1个，这不是bug，这是事故。

最简单粗暴的办法是给排班表的剩余号源加一个乐观锁。在 schedule 表加一个 version 字段，更新号源时带上版本号，更新的SQL长这样：

sql复制UPDATE schedule
SET remaining = remaining - 1, version = version + 1
WHERE schedule_id = #{scheduleId}
AND remaining > 0
AND version = #{version}

执行这条UPDATE后，通过返回受影响行数判断是否更新成功。如果返回0，说明version不匹配或者remaining小于等于0，说明号源已经被别人抢了，此时回滚事务，告诉用户“号源不足”。这个方案的好处是逻辑简单、性能好，不需要加数据库锁，很适合毕设展示。

除了乐观锁，还有一个容易忽略的问题：挂号成功后要正确记录订单状态，用户取消挂号后要把号源加回来。这个加回来的操作同样要注意状态判断——如果用户挂完号之后医生停诊了，号源不能直接加回排班表，要走停诊退号流程。这个边缘场景虽然不是核心功能，但代码里处理了，说明你思考问题全面，值得在文档里写一笔。

4.2 JWT登录鉴权与角色权限控制

系统有三个角色，每个角色的访问权限不一样。用户只能操作自己的订单，医生只能看自己的排班和接诊列表，管理员有后台管理的所有权限。这里我用SpringBoot + JWT（JSON Web Token）做无状态鉴权。

登录认证的流程是：用户提交手机号和密码，后端校验成功之后生成一个JWT令牌返回给前端。令牌里包含userId、角色、过期时间。前端拿到令牌后存在localStorage里，每次请求在HTTP头的Authorization字段带上。后端通过拦截器解析令牌，取出当前用户信息和角色，放行或拒绝请求。

Token有效期我设的是24小时，过期后就要求重新登录。这里有一个体验优化的细节：用户在操作过程中令牌过期了，不能直接把用户踢下线，而是由前端检测到后端返回的401状态码，弹出提示“登录状态已过期，请重新登录”，然后跳转到登录页。这个交互写进文档里，体现出你对完整业务流程的考虑。

4.3 前端页面与后端接口的对接方式

我用的前端方案是Vue + Element UI，后端提供RESTful接口。前后端分离，用Axios发请求。所有的接口统一返回一个Result对象，结构是这样的：

json复制{
  "code": 200,
  "message": "操作成功",
  "data": {}
}

所有接口都包一层，前端拦截器只需要判断code是不是200，如果不是200统一弹错误提示，不需要每个页面都写错误处理逻辑。这种统一返回结构的约定一定要在项目一开始就定好，不然前后端联调的时候每个人各写一套，接口风格乱七八糟，那才是灾难。

举一个接口设计的例子。推荐医生接口：

code复制GET /api/recommend/doctors?userId=1001&page=1&size=10

后端返回：

json复制{
  "code": 200,
  "data": {
    "total": 8,
    "list": [
      {
        "doctorId": 2001,
        "doctorName": "张医生",
        "title": "主任医师",
        "departmentName": "呼吸内科",
        "praiseRate": 0.98,
        "recommendScore": 0.87,
        "recommendReason": "根据您的症状描述，呼吸内科匹配度最高"
      }
    ]
  }
}

返回的数据既有医生的基础信息，又有推荐分数和推荐理由。前端拿到数据直接渲染卡片列表，不需要再做二次加工。接口字段名统一用驼峰命名，我见过有项目一半用下划线一半用驼峰，前端映射的时候各种小坑不断，这种细节很影响开发效率。

4.4 环境配置：Maven依赖与application配置示例

项目能跑起来是第一位的。这里贴一个Maven关键依赖配置，帮你避开最常见的坑。SpringBoot父级依赖用2.7.x版本，MyBatis starter用2.x版本，Redis starter用SpringBoot官方starter：

xml复制<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.mybatis.spring.boot</groupId>
        <artifactId>mybatis-spring-boot-starter</artifactId>
        <version>2.3.2</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
    <dependency>
        <groupId>com.auth0</groupId>
        <artifactId>java-jwt</artifactId>
        <version>4.4.0</version>
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <scope>runtime</scope>
    </dependency>
</dependencies>

配置文件的连接信息要对应你本地的环境。数据库连接串我建议加上 characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai，不加时区参数，MySQL 8.0版本连上会直接报时区错误。Redis连接默认端口6379，如果你本机Redis没改密码，配置里留空就行。

注意：本地安装Redis的时候，Windows版本下载地址经常失效。可以用目录下的压缩包解压，进入Redis目录执行 redis-server.exe redis.windows.conf 启动，再开一个窗口执行 redis-cli 测试连通。确保Redis服务先启动再启动SpringBoot项目，否则启动的时候连接Redis报错，项目起不来。

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

5.1 启动阶段最容易踩的五个坑

先列一个启动阶段的经典问题排查表，都是我实际见别人踩过、自己也无语过的坑：

有一个经验：启动报错不要慌，看错误信息最关键的一句话。很多人一看到JDBC connection就头疼，实则多半是密码错了，或库不存在。先把控制台从下往上读到第一个ERROR，那才是真正的根因。

5.2 推荐效果不理想：先检查数据再检查代码

很多同学把推荐模块写完之后发现推荐结果不准，比如用户明明输入“发热咳嗽”，推荐出来的却是骨科医生。遇到这种问题，按以下顺序检查：

第一步，检查数据。department 表的 symptom_keywords 是不是写错了？比如“呼吸内科”的适用症状里漏了“发热”两个字，那匹配度就会算错。第二步，检查预处理。用户输入的症状有没有做标准化？比如用户输入“发烧”，而症状词库里只有“发热”，匹配不到，推荐结果自然就是空的。解决办法是维护一个同义词映射表，发烧→发热，头疼→头痛，拉肚子→腹泻，这种映射对推荐效果提升非常明显。第三步，检查权重。如果内容推荐权重太低，即使匹配度高，混合排序后也可能被协同过滤的结果压在后面，适当调整权重系数。

5.3 打包部署环节：从本地到服务器的实操拆解

毕业设计的验收通常需要部署到云服务器上。我建议提前两周开始搞部署，别拖到最后一天。部署方案推荐用Docker，环境隔离、迁移方便、答辩的时候还能说“我用了容器化部署”，加分。

第一步，数据库初始化。把本地的SQL文件导入服务器的MySQL，检查数据是否完整。第二步，打包SpringBoot项目。在项目根目录执行 mvn clean package -DskipTests，生成JAR包。第三步，写Dockerfile。基础镜像用 openjdk:8-jre，把JAR包复制进去，指定启动命令。第四步，用docker-compose编排SpringBoot和Redis两个容器，一次性启动。第五步，配置Nginx反向代理，把80端口转到项目的8080端口，前端静态资源也由Nginx托管。

整个流程里最容易翻车的是JAR包内容没有包括配置文件。要检查 spring.profiles.active 指向的环境配置文件是否被打进包里，或者是否通过环境变量 SPRING_PROFILES_ACTIVE=prod 指定了环境。我见过太多人本地跑得好好的，部署到服务器之后报“数据库连接失败”，一查就是配置文件没有切换到生产环境。

5.4 答辩前必做的自查清单

项目跑起来只是第一步，答辩的时候老师不只看效果，更看你的理解深度。我整理了一个自查清单，你可以对照着检查：

• 能不能清晰说出推荐算法的原理，为什么选协同过滤和内容过滤混合？
• 如果老师追问“你的系统怎么防止号源超卖”，你能答出乐观锁吗？
• 如果老师问“用户行为数据是怎么收集的”，你能说出埋点方案吗？
• 数据库表之间的主外键关系，你能不看文档画出来吗？
• 系统的扩展点是什么？比如未来怎么接入在线支付？

最后一个问题特别重要。老师几乎必问：“你未来怎么扩展？”一旦被问住，前面再好的表现都会打折。我的建议是准备好两个可扩展的方向：第一，推荐算法可以升级为基于深度学习的排序模型，把更多特征（比如用户地理位置、天气因素、医生语音问诊记录）纳入模型；第二，业务上可以扩展在线支付、电子病历、远程问诊等功能模块。这两个方向既有技术深度又有业务想象空间，能体现你的思考能力。

6. 收官阶段的实用建议

项目写完了，还有一个看起来表面但实际影响很大的环节——写项目文档和准备答辩演示。很多同学习惯于把代码写完就万事大吉，但其实毕业设计的分数线，一半看代码实现，一半看文档和表述。

写文档的时候，核心架构图、用例图、E-R图、接口文档这几样一定要准备齐全。E-R图用工具画清楚，标注好主键和外键；用例图画清楚三个角色的操作边界；接口文档写清楚每个接口的入参、出参、异常情况。这些材料不仅是给老师看的，更是给你自己梳理思路用的。我在实际维护项目的过程中，经常需要回头看接口文档，不然时间一长真的会忘记某个接口的完整逻辑。

再说一个答辩演示时的小技巧：准备一套干净的演示数据。演示当天先把模拟用户的数据清零，重新跑一遍模拟脚本，生成一批看起来真实但不杂乱的数据。演示的时候先走一遍用户端完整流程：注册登录、输入症状、查看推荐科室和医生、挂号成功，再去医生端接诊，最后到管理员后台看统计数据。整个流程一气呵成，老师的第一印象就是“系统完整度高、逻辑跑通了”。

关于源码和文档的整理，我再多说一句。项目目录里不要留一堆 test1.java、临时修改.java 这类乱七八糟的文件。把代码结构整理干净，必要时写一个README文档，把启动步骤、默认账号密码、注意事项写清楚。这不光是给老师看的，也是给未来的自己看的——毕业后翻出来，你还能很快跑起来这个项目，那才是真的做完了。

最后分享一点个人感受。每年带毕设，我都会发现一个规律：真正把系统完整做下来的人，和只想着凑合交差的人，在答辩场上高下立判。前者能自信地讲出每一行关键代码背后的权衡，后者面对追问只能支支吾吾。做这个医疗挂号推荐系统，你收获的不仅是一个毕业设计分数，更是一套完整的前后端开发思维。这套思维，在你之后找实习、写项目、进团队的时候都会受益。祝正在做这个题目的你，答辩顺利。