企业官网建设流程全解析

1. 社区医院挂号就诊管理系统：这个毕设题目为什么值得做

每年到毕业季，Java方向的学生选毕设题目，十个里有八个绕不开“基于Spring Boot的某某管理系统”。说实话，这类题目被做烂了，但“社区医院挂号就诊管理系统”依然是个很典型的样本——它不是一个单纯堆CRUD的管理后台，而是把线上挂号、医生排班、接诊、开处方、缴费这几件事串成了一条完整业务链。做一次这个项目，等于把Spring Boot生态里最常用的东西全部过了一遍：数据访问、权限校验、业务状态流转、甚至简单的并发控制。

我见过太多学生拿到这类项目源码之后，第一步就是犯难：代码能编译，但一运行就报数据库连接失败；页面能打开，但挂号老提示“该时段已满”；文档写得像流水账，答辩时老师随便一问就露馅。这篇文章不是来贴广告的，而是借这套“社区医院挂号就诊管理系统”的完整设计过程，把从选题分析、表结构设计、核心接口实现到远程调试、论文撰写、答辩准备这一整套经验写出来。无论你是准备自己做，还是拿到一套源码想真正跑明白，这篇文章都能帮你省下大量踩坑时间。

为什么拿这个题目做例子？因为它足够小，不至于让人淹没在代码里；又足够完整，覆盖了实际业务系统常见的三个关键词：业务闭环、技术栈组合、可演示性。线下社区医院的流程并不复杂：患者在自助机或前台挂号，找对应科室的医生看诊，医生开处方，患者去药房取药或去收费处缴费。这套系统就是把线下的这几个环节搬到了线上，所以理解起来非常直观，也很方便向答辩老师解释。

适合谁来读这篇文章？两类人。一类是准备做Java毕设的学生，你可以把这篇文章当设计说明书的大纲来用；另一类是刚入门Spring Boot、想找一个完整项目练手的开发者，这套系统麻雀虽小，但五脏俱全，能让你看到真实项目里登权、事务、异常处理、状态管理到底是怎么落地到代码里的。

2. 需求拆解：从“线下医院流程”到“线上系统功能”

2.1 角色与权限边界：先分清楚谁在用这套系统

很多人做管理系统，上来就写代码，结果做着做着发现乱成一团。正确做法是先列角色，再列每个角色能干什么。社区医院的就诊流程里，参与的人至少有三类：患者、医生、系统管理员。如果再把挂号窗口的工作人员单独算，可以拆成四类，但对毕设而言，三类角色已经足够，把护士和窗口人员合并到管理员里就可以。

患者（普通用户）：注册登录、查看科室和医生信息、按日期查看医生排班、在线挂号、查看自己的挂号记录和就诊历史、查看待缴费和已缴费记录。医生：查看今日我的排班和候诊患者列表、开始接诊、填写诊断结果、开处方（选择药品和用法用量）、结束本次就诊。管理员：科室管理、医生信息管理、排班管理、用户管理、药品管理、就诊记录查询以及一些简单的统计报表。

这三类角色之间是有明显边界的。比如患者不能给自己写诊断，医生不能修改其他科室的排班，管理员不应看到普通用户的具体密码。这些边界落实到系统里，就是接口权限控制。最简单的方式是登录后返回一个角色标识，后端写一个拦截器，对敏感接口做角色校验。别嫌这一步麻烦，答辩时老师几乎一定会问“你们怎么保证普通用户无法调用医生接口”，这是加分项。

2.2 核心业务流程：一次完整的就诊事件是怎么串起来的

在设计表结构和代码之前，要把业务流程画清楚。我习惯用一条主线来描述社区医院的就诊过程：患者注册登录，选择科室和医生，查看医生的排班表，选择一个尚未满号的时间段提交挂号；挂号成功后生成一条挂号记录，状态为“待就诊”；医生登录系统后看到候诊列表，点击“接诊”，挂号记录变成“就诊中”；医生填写诊断、开出药品处方，点击“完成就诊”，记录变成“已完成”；患者查看自己的就诊记录，看到待缴费的处方，模拟缴费后状态变成“已缴费”。

这条链路里最关键的设计不是某个接口，而是挂号记录这个核心对象的状态。状态怎么流转、谁在什么时候修改状态，这比写十个CRUD接口都重要。后面讲代码时我会专门展开。

2.3 功能清单与开发优先级：先做骨架，再填肉

拿到题目之后不要急着写代码，先列功能清单，并给功能排优先级。我给这套系统的建议排序是这样的：

P0核心链路（必须先做）：用户注册登录、科室与医生展示、医生排班、在线挂号、医生接诊与写诊断、缴费记录。 P1重要功能（影响体验）：管理后台的基础维护（科室、医生、排班、药品）、挂号与就诊状态查询、简单的统计图表。 P2可选扩展（时间有余再做）：短信/邮件通知、支付接口模拟、电子病历导出、患者评价。

为什么这么排？因为毕设答辩评分的核心是可演示性，而演示的核心是主线闭环——从注册挂号到医生开药这个链路必须顺畅。很多同学上来就做后台管理界面，做了很多漂亮的增删改查，结果主线业务没走通，演示时卡在挂号环节，那就很难受了。

3. 技术选型的底层逻辑：Spring Boot + MyBatis-Plus 为什么是首选组合

3.1 后端框架：Spring Boot 3.x 还是 2.7？

现在新建Spring Boot项目，官方推荐的已经是3.x版本，但对毕设来说，3.x不一定是最优解。原因有两个：一是很多国内教程、博客、开源代码还停留在2.x，碰到问题搜到的解决方案可能不兼容；二是Spring Boot 3.x基于Jakarta EE，部分老代码里的javax要改成jakarta，如果拿到一份旧源码要升级，光改包名就够折腾。我的建议是，如果从零开始写，用2.7.x版本最稳；如果想让项目看起来新一点、愿意踩坑，用3.2.x也可以，注意JDK要用17以上。

为什么整个后端框架要选Spring Boot？因为社区医院挂号就诊系统本质上是一个以数据库操作为核心的Web应用。Spring Boot把配置简化到了极致，内嵌Tomcat，不用打WAR包，一个java -jar就能跑起来，这对学生党来说太友好了。而且Spring生态的整合能力很强，接Redis、接MyBatis-Plus、做拦截器，都是几行配置的事。

3.2 ORM选型：MyBatis-Plus帮你省下一半工作量

选MyBatis-Plus的理由很简单：单表CRUD不用写SQL。比如用户表的增删改查、科室表的分页查询、药品表的条件搜索，MyBatis-Plus的BaseMapper直接提供selectPage、selectList、selectById等方法，实体类加几个注解就能用。这对时间紧张的毕设来说价值巨大。

但要注意两点。第一，MyBatis-Plus虽然省事，但复杂的多表查询还是要自己写XML或注解SQL，不要试图把一切都塞进Wrapper里，硬写会导致代码极难阅读。第二，分页查询要记得添加分页插件拦截器，否则PaginationInnerInterceptor没有注册，分页会失效，查出来的结果是全量数据。这个问题非常隐蔽，答辩现场翻车率很高。

3.3 前端方案：服务端渲染还是前后端分离？

很多同学纠结前端怎么做。我的建议是：以稳为主。如果你对Vue不熟，就老老实实用Thymeleaf模板引擎加Bootstrap，服务端渲染，路由和后端接口是一个整体，部署非常简单，也不存在跨域问题。如果你Vue基础还可以，那用Vue3 + Element Plus做前后端分离，后端提供纯JSON接口，前端单独起一个Vite项目，视觉效果会好看很多，但也要承担跨域配置、Token传递、生产构建后部署的额外复杂度。

对毕设而言，我见过太多因为前端分离带来跨域问题而卡住的项目。如果目标是稳定演示，Thymeleaf + Bootstrap是性价比最高的选择；如果想在“技术亮点”里写上“前后端分离”，那就要把CORS配置和部署流程提前测通。

3.4 缓存与验证码：Redis在什么场景下真正发挥作用

社区医院系统里Redis不是必需品，但加上它可以说清两个问题：一是验证码的存储，二是Token的校验。验证码如果用Session存，在前后端分离模式下会遇到跨域Session不一致的问题；用Redis存，设置过期时间，天然支持分布式场景，答辩时也更好讲。Token方面，如果是无状态JWT方案，Redis不是必须的；但如果你想实现“强制退出登录”或者“服务端注销Token”，就得把Token存一份到Redis里。

毕设项目中Redis不要让所有数据都往里塞。保持简单，只存验证码、存一些热点科室信息、存登录Token的黑名单，这样就够了。在论文里也可以写一句“Redis用于缓解数据库压力并支持分布式部署”，这是很常见的话术，前提是你确实用了。

3.5 工程结构：包名和分层是给别人看的，也是给未来的自己看的

一个规范的项目结构应该让人一眼看懂。我常用的分包方式是：controller、service、mapper、entity、dto、vo、config、common、utils。controller只接收参数、调用service、返回结果；service里写业务逻辑；mapper里放数据库访问；dto用于接收前端入参，vo用于返回前端数据。实体类entity和表字段一一对应。

另外一定要有一个统一的返回体，比如Result 。它包含code、message、data三个字段。别小看这个类，如果一开始不统一，后面的接口有的返回Map，有的返回String，有的直接返回实体，联调的时候你会想砸电脑。统一了返回体之后，前端处理数据也简单，只需判断code是不是200。

4. 数据库与核心代码：一步步实现完整就诊闭环

4.1 表结构设计：用八张表还原医院业务

数据库设计是这套系统最重要的部分，它决定了后续代码好不好写。我的建议是不要追求表数量多，而要追求“每一张表都有明确职责”。八张表足够：用户表user、科室表department、医生表doctor、排班表schedule、挂号表registration、病历/就诊记录表medical_record、药品表drug、处方表prescription（处方明细表）。

核心表字段给你拆一下。

用户表：id、用户名、密码（加密存储）、姓名、手机号、角色标识（patient/admin）、创建时间。密码必须加密，用BCrypt，不要明文存。

医生表：id、用户id（关联user账号）、姓名、所属科室id、职称、简介。注意医生本身可以是一个用户，这样医生也能登录系统，他的用户角色是doctor。

排班表：id、医生id、排班日期、时段（比如上午/下午）、剩余号源、总号源。这里的剩余号源是挂号并发控制的关键字段。科室表：id、科室名称、位置、简介。

挂号表：id、患者id（关联user）、排班id、医生id、科室id、挂号时间、挂号费、状态（待就诊/就诊中/已完成/已取消/已缴费）。

病历表：id、挂号id、患者id、医生id、主诉、诊断结果、创建时间。处方表：id、病历id、药品id、药品名称（冗余）、数量、用法用量、金额、缴费状态。

这里有一个设计要点：为什么处方表里要冗余药品名称？因为药品价格和名称如果只关联drug表，一旦药品信息被修改，历史处方也会跟着变，这在业务上是不合理的。毕设里你不需要做太完整的历史快照，但把名称和价格冗余下来，是一个很加分的细节。

注意挂号表和排班表的关联：挂号表上的排班id指向具体某一时段，而“是否满号”是通过排班表的剩余号源判断的。后面讲并发时你会看到这个字段怎么用。

建表语句给一个示例，以挂号表为例：

CREATE TABLE `registration` ( `id` bigint NOT NULL AUTO_INCREMENT, `patient_id` bigint NOT NULL COMMENT '患者用户id', `schedule_id` bigint NOT NULL COMMENT '排班id', `doctor_id` bigint DEFAULT NULL, `department_id` bigint DEFAULT NULL, `register_time` datetime DEFAULT CURRENT_TIMESTAMP, `fee` decimal(10,2) DEFAULT '0.00', `status` tinyint DEFAULT '0' COMMENT '0待就诊 1就诊中 2已完成 3已取消 4已缴费', PRIMARY KEY (`id`), UNIQUE KEY `uk_schedule_patient` (`schedule_id`, `patient_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意最后那行唯一索引，它保证了同一个患者不会重复挂同一个时段的号。这是防重复挂号的第一道防线。

4.2 登录认证：JWT实现更能体现对无状态的理解

毕设登录认证有两个方案，Session方案简单，JWT方案更“现代”。如果你想让答辩更有亮点，用JWT。JWT把用户id和角色签在Token里，后端不再存Session，天然适合前后端分离和水平扩展。核心是一个工具类，生成Token并解析Token。

@Component public class JwtUtils { @Value("${jwt.secret}") private String secret; @Value("${jwt.expire}") private Long expire; public String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + expire)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); } }

登录接口的逻辑很简单：根据用户名查出用户，用BCrypt校验密码，匹配后生成Token返回给前端。前端之后每次请求都带上Authorization请求头。拦截器里对所有需要登录的接口做校验，再通过路径匹配判断是否需要管理员权限。拦截器代码不长，但它是权限管控的基石。

4.3 挂号接口：防止同一个号被抢两次

挂号是这个系统里最有技术含量的一个接口。表面上它只是insert一条挂号记录，但实际要考虑：排班是否存在、该时段是否还有号、当前用户是否已经挂过、事务一致性怎么保证。我给出一个简化但完整的实现思路。

@Transactional(rollbackFor = Exception.class) public Result register(RegisterDTO dto, Long patientId) { // 1. 查询排班 Schedule schedule = scheduleMapper.selectById(dto.getScheduleId()); if (schedule == null) { return Result.error("排班不存在"); } // 2. 判断是否已满 if (schedule.getRemaining() <= 0) { return Result.error("该时段号源已满"); } // 3. 判断是否重复挂号 Long count = registrationMapper.selectCount( new LambdaQueryWrapper<Registration>() .eq(Registration::getScheduleId, dto.getScheduleId()) .eq(Registration::getPatientId, patientId)); if (count > 0) { return Result.error("您已挂过该时段，请勿重复挂号"); } // 4. 扣减号源（乐观锁） int updated = scheduleMapper.deductRemaining(dto.getScheduleId()); if (updated == 0) { return Result.error("号源刚被抢完，请选择其他时段"); } // 5. 插入挂号记录 Registration reg = new Registration(); reg.setPatientId(patientId); reg.setScheduleId(dto.getScheduleId()); reg.setDoctorId(schedule.getDoctorId()); reg.setDepartmentId(schedule.getDepartmentId()); reg.setFee(schedule.getFee()); reg.setStatus(0); registrationMapper.insert(reg); return Result.success("挂号成功"); }

关键在第四步的deductRemaining，对应的SQL是：

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

这种写法叫乐观锁。它利用数据库的行锁，保证多个用户同时抢最后一个号时，只有一个人能执行成功。如果没有这行SQL，纯粹靠先select再update，就会出现超卖——最后一个号被两个人同时看到剩余1，然后都挂了号，但是号源变成负数。这个坑在并发测试时很容易暴露，答辩时老师也爱问。

4.4 医生接诊与开处方：用一个状态机串联整条链路

患者挂号成功后，接诊流程实际上就是在操作registration表的状态。我给了一个简单的状态流转，代码里可以用一个静态状态机类管理，也可以用枚举。对毕设来说，我建议在service层清晰写出每一步的校验逻辑，比引入复杂状态机框架更稳妥。

医生登录系统后，先查“今日候诊列表”，本质就是：查询该医生名下status等于0（待就诊）的挂号记录，按挂号时间排序。点击“接诊”时，需要校验当前记录状态确实是0，然后把状态改成1。这一步能防止两个医生同时接诊同一患者的问题。

填完病历后，调用“完成就诊”接口：更新病历表、插入处方明细、把挂号状态改为2（已完成）。患者端查看待缴费记录时，关联处方表查出未缴费的药品和金额。模拟缴费的接口把状态改为4（已缴费）。

这里最常见的问题是事务没加。比如“完成就诊”时既要写病历，又要写处方，还要改挂号状态，三个操作如果中间任何一个报错，前面成功的操作也会留下“半成品”数据。所以这个接口务必使用@Transactional注解。

4.5 管理后台与统计报表：让数据“可视化”

管理员的统计报表是很多人忽略的模块，但它对答辩很有用。不需要做得多复杂，三张图就够：近一周每日挂号量柱状图、各科室挂号量占比饼图、医生接诊量排行榜。数据来源就是登记表的分组聚合。

核心SQL很简单：

SELECT DATE(register_time) AS day, COUNT(*) AS cnt FROM registration WHERE register_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(register_time);

前端用ECharts的CDN渲染就行，不需要复杂图表框架。这一模块做完，论文里的“系统测试”和“功能展示”章节就有素材了，而且演示时一打开就能看到图表，直观性很强。

5. 实操实录：从空项目到完整演示的完整流程

5.1 环境准备与项目初始化

先列一下我推荐的环境：JDK 8或11（对应Spring Boot 2.7）、Maven 3.6+、MySQL 5.7或8.0、IDEA 2022以上版本。如果你用Spring Boot 3.x，JDK要17以上。

创建项目有两种方式：用IDEA的Spring Initializr，或者直接去start.spring.io下载压缩包。这里提个醒，start.spring.io默认生成的可能是最新版Spring Boot，如果发现版本太高导致依赖下载异常，可以手动降到2.7.18。我在网上看到好多人卡在“springboot版本太高”这个问题上——版本太高本身没毛病，但很多第三方库和教程还没跟上。对稳定优先的毕设项目，2.7.18真的够用了，没必要追新。

5.2 核心配置：application.yml的常见坑一并解决

配置文件是启动的第一道坎。一套能直接用的配置大概长这样：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

这里最容易踩的坑有三个：一是MySQL连接URL里忘加serverTimezone，导致报时区错误；二是useSSL设成true，控制台刷一堆SSL警告但不算致命；三是MySQL 8.0的驱动类必须是com.mysql.cj.jdbc.Driver，不要用旧的com.mysql.jdbc.Driver。

Redis如果不装，可以在配置里暂时注释掉Redis相关starter依赖。验证码存储可以先改成Session实现，等Redis装好了再切回来。这样能降低前期环境搭建的难度。

5.3 主流程测试：注册→挂号→接诊→缴费，一步步验证

项目跑起来之后，不要急着截图写文档，先按业务主线把所有接口测一遍。我的测试路径是：

第一步，注册一个患者账号，确认密码是加密存储的。第二步，用患者账号登录，获取Token，访问科室列表和医生排班接口，确认返回数据正常。第三步，选一个上午有号的排班，调用挂号接口，再重复调用一次，确认能拦截重复挂号。第四步，登出患者账号，登录医生账号，查“今日候诊列表”，对刚才那条挂号记录执行“接诊”。第五步，填写主诉、诊断，选择药品，提交处方，完成就诊。第六步，回到患者端，查看就诊记录和待缴费列表，执行模拟缴费。第七步，用管理员账号登录，查看统计报表，确认图表数据有更新。

整个流程测下来，如果没出问题，说明核心业务闭环是通的。任何一步报错，都建议回到对应接口的controller和service看日志。很多毕设源码的问题都出在数据库时间字段、空值判断、角色校验这几个地方。

5.4 远程调试：怎么让老师远程看到你的运行效果

标题里提到的“远程调试”是这个项目的卖点之一，也是我特别想展开的地方。很多人以为远程调试很玄，其实就是一个IDEA自带的功能：把运行中的后端程序开启Debug端口，然后从另一台机器连接上去看日志、打断点、追踪变量。

具体操作分三步。第一步，在服务端启动参数里加一段JVM参数：-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005。如果项目是打包成jar在服务器上跑，命令就可以写成：

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -jar hospital-system.jar

第二步，在本地IDEA的Run/Debug Configurations里新增一个Remote JVM Debug，Host填服务器的公网IP，Port填5005，然后点击Debug按钮。第三步，本地IDEA会连接上远端JVM，之后你在本地打断点，远端请求打到这个位置时就会停下来，方便随时查看变量。

这里提醒一句：远程调试端口不要暴露在公网上太久，调试完就关掉，否则有安全隐患。给老师演示时，更稳妥的做法是把项目部署到云服务器，然后在浏览器里正常访问页面，远程调试只作为排查问题的辅助手段。有些同学把本地项目用一些工具映射到公网让老师访问，我建议慎重，这类工具不稳定，而且存在数据安全风险。

6. 常见问题速查：我踩过的坑和排查思路

6.1 启动阶段的经典报错

端口被占是最常见的。报错信息里会出现“Port 8080 was already in use”，解决办法是把8080的进程找出来关掉，或者在配置文件里换个端口。Linux下用netstat -tunlp | grep 8080查进程，Windows下用netstat -aon | findstr "8080"查PID，然后taskkill /PID xxx /F。

数据库连不上的报错五花八门：Access denied是密码错误；Communications link failure多半是MySQL没启动，或者URL里的IP/端口不对；Unknown database是库不存在，先去MySQL里执行source建库脚本。很多同学拿到源码，改了密码就以为完事了，其实还要确认编码建库、UTF-8字符集这些细节。

依赖下载慢也是经典问题。Maven中央仓库在国内访问很慢，在settings.xml里加阿里云镜像即可。还有一个容易踩的坑：本地Maven仓库里缓存了不完整的jar包，导致一直报找不到类。解决办法是删除对应目录让Maven重新下载。

6.2 MyBatis-Plus使用中的高频坑

逻辑删除是很多人没留意的大坑。如果我在配置里加了logic-delete-field: deleted，那所有实体类的查询都会自动带上“deleted=0”条件。好处是删除变软删除，坏处是如果你表里没有deleted字段，或者字段名对不上，所有查询都会报错“Unknown column 'deleted'”。所以要么所有表都加deleted字段，要么不要在全局配置里开逻辑删除，只在需要的表上单独用注解。

自动填充也常出问题。create_time和update_time如果用数据库里的CURRENT_TIMESTAMP就没必要交给MyBatis-Plus处理。如果要统一在代码里处理，需要实现MetaObjectHandler接口，并给实体字段加@TableField(fill = FieldFill.INSERT)注解。否则插入时时间就是null，数据库时间字段会报错。

分页插件不生效之前讲过：没有注册PaginationInnerInterceptor。这个插件必须在MybatisPlusInterceptor里添加，而且要放在拦截器链的合适位置。检测方法很简单，看分页SQL是否带了LIMIT，如果没带，基本就是插件没注册。

6.3 前后端接口与页面问题

如果是Thymeleaf项目，静态资源404多半是路径问题。Spring Boot默认静态资源位置是classpath:/static/，模板放在templates下。Controller返回视图名时不要带后缀，Thymeleaf会自动拼接。比如return "index"会找到templates/index.html。

如果是前后端分离项目，跨域问题几乎是必踩的。后端需要配置CorsFilter或者用@CrossOrigin注解，前端要注意请求路径是否加了/api前缀。还有一种情况：前端请求带上了Token，但后端拦截器放行了OPTIONS预检请求，导致跨域预检失败。这个坑很隐蔽，很多项目明明加了CORS还是报跨域，就是预检请求没处理。

页面报“Template might not exist or might not be accessible”这种错，一般是模板路径写错了，或者文件名拼写不一致。Windows下大小写不敏感可能没暴露问题，但Linux服务器上就立刻翻车。

6.4 并发与数据一致性问题

挂号超卖问题前面已经给过方案，这里补充另一个相关场景：取消挂号。患者取消挂号时，挂号记录状态改成已取消，同时排班表的remaining要加回1。这里很容易忘记恢复号源，导致后期明明没人挂号却显示满号。我在项目里遇到过，排查了很久才发现是取消接口没写“号源回补”的逻辑。

另外一个数据一致性场景是“完成就诊”时写了病历但没写处方。虽然加了事务可以解决，但很多人会忘记在同一个事务类里调用方法时事务失效的问题——当类内部通过this调用另一个带@Transactional的方法时，事务注解是不生效的，因为代理对象没有被触发。实际开发中最好把事务方法拆到不同Service类，或者自己注入自己。

7. 文档、答辩与扩展：让毕设从“能跑”变成“能讲”

7.1 毕设说明书怎么写才能撑满篇幅

很多人的论文写得像流水账，一个章节放几十行代码，没有任何分析。我的建议是：图表比代码值钱，流程比List值钱。需求分析章节配上用例图，数据库设计章节放ER图并解释每张表的关键字段和关联关系，核心功能章节对挂号、接诊、缴费这三个模块做时序图加文字说明。这些图用StartUML或者ProcessOn画就行，不需要太专业，清晰即可。

每个章节的篇幅安排也有讲究。我见过最合理的比例大概是：绪论和背景占15%，需求分析占15%，系统设计占25%，数据库设计占20%，功能实现占15%，测试占10%。注意功能实现不要整段贴代码，只贴关键代码块，并说明这段代码解决了什么问题。比如贴出号源扣减SQL，然后解释为什么用乐观锁防止超卖，这就比贴100行分页代码有价值得多。

7.2 答辩现场老师最爱问的几个问题

根据我围观和参与答辩的经验，老师们其实不太会问特别刁钻的技术问题，他们关注的是“这项目是不是你写的”和“你对核心逻辑是否理解”。

高频问题一：为什么选Spring Boot？答：自动化配置降低开发成本，内嵌服务器部署简单，生态成熟适合快速开发。高频问题二：MyBatis-Plus和MyBatis有什么区别？答：MyBatis-Plus提供通用Mapper和条件构造器，单表CRUD不用写SQL，但复杂查询仍需要自定义SQL。高频问题三：Redis缓存了什么数据？缓存失效怎么处理？答：缓存了验证码和热点科室信息，设置过期时间，更新数据时主动删除缓存以保证一致性。高频问题四：挂号并发你怎么解决的？这个问题前面已经详细讲过，能说清楚乐观锁和唯一索引就算过关。高频问题五：项目有什么不足？这个问题不要答“没有”，可以诚恳地说“目前的缴费是模拟的，没有对接真实支付网关；权限控制基于角色，粒度还可以细化”。这反而会显得你有思考深度。

7.3 想拿优秀论文的扩展方向

如果时间和能力允许，可以在基础项目上做三个方向的扩展。

第一个方向是增加在线支付模拟，比如对接一个沙箱支付平台，或者自己实现一个“虚拟钱包”，充值、扣费、退款一套流程走下来。第二个方向是增加微信小程序端，患者在小程序里挂号、查报告，Web端做管理后台。这能让项目从“管理系统”升级成“移动互联网应用”，答辩的视觉冲击力完全不一样。第三个方向是引入消息通知，比如挂号成功、就诊提醒用邮件或短信发送，后端对接消息队列或简单的异步任务。

但我要说句实在话：扩展功能一定要量力而行。我见过不止一个同学，前面基础功能还没稳定就想着加小程序，最后两边都没做好。先把主线功能和文档打磨好，扩展功能是锦上添花，不是雪中送炭。

8. 最后分享一点实际体会

做这类Spring Boot毕设项目，我最大的体会是：代码写得多不如流程走得通。很多学生能写出几百行代码，但在把整个挂号就诊流程串起来时卡住了，原因往往不是某个技术难点，而是对业务状态流转理解不透。拿到任何一套项目源码，我建议第一件事不是看代码，而是先把数据库表结构和核心状态枚举理清楚。表与表之间的关系、每个状态在什么条件下变更，这两件事想明白了，代码读起来就会顺畅很多。

另外，远程调试这个能力，别等到毕设快交了才学。哪怕项目在你本机上，学会用Debug模式打断点、查看调用栈、条件断点，对排查问题的帮助非常大。我在帮别人排查问题时发现，超过一半的同学根本不会用调试器，只知道在代码里加System.out.println，然后重新启动，效率极低。

这套系统是社区医院场景，但它其实代表了一整类“流程型管理系统”的设计方法。今天你掌握了挂号、接诊、缴费这条状态链，换到教务系统、图书管理系统、实验室预约系统，核心套路是通用的。这也是我为什么愿意花这么大篇幅讲状态流转和并发控制，而不是堆功能截图的原因。希望这篇文章能把你在毕设路上走的一些弯路省掉，祝你顺利。