每年到了毕业设计选题季，总有一批学弟学妹来找我问同一个问题：到底选什么题目能既顺利通过答辩，又不至于把自己折腾到崩溃。见多了那些一上来就冲电商秒杀、社交聊天、甚至AI算法的题目，最后却在开题阶段就卡住的情况，我越来越觉得，像"基于SpringBoot的校医院管理平台"这种管理信息系统类题目，才是被严重低估的稳妥之选。业务边界清晰、技术栈主流、工作量可控制、答辩时又有话可说，这四个条件凑齐了，做起来是真的省心。
这篇内容我会按自己当年带项目、带毕设的实际经验来拆解这个题目。不管你是正为开题发愁，还是已经写到了核心模块，又或者答辩前心里没底，照着下面的思路去梳理，基本可以把整条路线走通。
1. 为什么说"校医院管理平台"是被低估的毕设选题
校医院在高校里是一个非常特殊的场景。它面向的是教职工和学生，业务规模不如三甲医院那么庞大，但麻雀虽小五脏俱全——门诊挂号、医生接诊、药品划价、体检预约、健康档案，这些流程一个都不少。正因如此，它天然适合作为毕业设计的信息化改造对象：既有真实的业务痛点可讲，又不会因为需求过于复杂导致代码量失控。
很多同学担心"管理系统"类题目太老套，评审老师一眼就能看出工作量。但我建议换个角度来看这件事：毕设的核心目标是证明你具备独立完成一个软件项目的能力，而不是发明一个全新的业务模式。校医院平台能展示的东西其实非常集中：
- 业务链条完整：从预约挂号到医生开方，从药品扣库存到费用记录，至少能串起三四条相互关联的业务流，这比单体CRUD展示出来的系统性强得多。
- 角色权限分明：管理员、医生、前台/药房、患者（学生或教师），不同角色看到的界面和能做的操作完全不同，正好用来体现你对权限设计的理解。
- 技术栈有发挥空间：SpringBoot负责后端接口，Vue做前端页面，Redis管登录态和缓存，MySQL存业务数据。这套组合是目前Java就业市场的主流配置，写在简历上也有含金量，总比JSP+Servlet老旧组合有说服力。
- 答辩素材丰富：预约挂号的并发控制、药品库存的扣减策略、Token认证的过期续期，随便挑一个展开讲都能讲上好几分钟，不怕老师问几句就冷场。
还有一点容易被忽略：校医院平台的数据量级和业务复杂程度刚刚好。你要是去做一个全功能的医院信息系统，光医保对接和LIS/PACS检验检查联动就够你喝一壶了。校医院场景把这些高难度的集成全部简化掉，保留的是最核心的业务骨架，正适合在几个月内独立完成。
2. 技术选型与核心架构拆解
我当时给这个题目定下的技术组合是这样的，每一层都有明确的目的，不建议随意替换成太偏门的东西。
2.1 后端基础：SpringBoot版本怎么选
SpringBoot我推荐用2.7.x系列，配合JDK 8。不推荐一上来就追最新的SpringBoot 3.x，原因很现实：3.x要求JDK 17及以上，虽然性能更好，但市面上大量教程、开源代码、毕设参考资料还是基于2.x写的。你自己会踩很多坑，想搜个解决方案，网上答案多半不能直接用。毕业设计求稳优先，不要给自己增加不必要的变量。
在pom.xml里引入必要的依赖时，尽量保持一致：
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <dependencies> <!-- Web支持 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis-Plus，后面细讲 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- Redis做登录态与缓存 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <!-- JWT --> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> <!-- Lombok，减少样板代码 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>2.2 ORM选型：为什么是MyBatis-Plus
现在让我去手写一套Hibernate或者原生MyBatis的XML映射，我不会说不行，但它不适合毕设这种时间紧张的项目。MyBatis-Plus提供的基础CRUD能力——insert、deleteById、selectPage、lambdaQueryWrapper——可以让你把百分之六十的重复性数据库操作直接省掉，把精力集中在业务逻辑最复杂的部分。
尤其是它的代码生成器（MyBatis-Plus Generator），可以根据数据库表结构直接生成实体类、Mapper接口、Service接口和实现类，生成之后再手工调整，效率极高。我当时建完二十多张表之后，用生成器跑一遍，十几分钟就把骨架代码全部搞定，剩下的时间全花在写真正的业务判断上。
一个容易踩的坑是逻辑删除配置。校医院的数据涉及就诊记录和药品出入库，这些历史数据不能物理删除，比如误操作把某条处方删了，账目就对不上。MyBatis-Plus提供的@TableLogic逻辑删除注解，可以在执行delete方法时自动转换成update set deleted=1，这类细节在答辩时讲出来是加分项。
2.3 认证方案：JWT配合Redis，而不是单纯Session
校医院平台是典型的前后端分离项目，前端Vue部署在一台服务器，后端SpringBoot部署在另一台，这种情况下传统的Session方案天然不适用。跨域请求携带Cookie本身就有诸多限制，所以登录认证我选择了JWT + Redis的组合。
流程是这样：
- 用户登录成功后，后端生成一个JWT，里面带上用户ID、角色信息和过期时间。
- 同时把该JWT存入Redis，设置过期时间（比如2小时），作为服务端可控的登录凭证。
- 前端拿到JWT后存在localStorage里，每次请求在HTTP Header中加入
Authorization: Bearer <token>。 - 后端通过自定义拦截器或Spring Security过滤器对请求进行拦截，解析JWT，再从Redis里校验token是否存在、是否已过期。
这样做有一个明显的好处：如果要强制用户下线，直接把Redis里的token删掉就行，不用等JWT自然过期。另外，后端改了密码之后旧token还在有效期内的安全隐患，也可以通过Redis校验来规避。以后在简历上写"基于JWT和Redis的分布式登录认证方案"，面试官一听就知道你是理解过原理的。
2.4 整体架构：前后端分离配合统一返回体
前后端分离已经是现在的主流默认选项，除非导师明确要求必须用模板引擎（比如Thymeleaf），否则不要在这个问题上过度纠结。Vue + Element Plus做后台管理界面，组件丰富、写起来快、界面也不丑，答辩演示时视觉效果远胜传统JSP页面。
前后端联调的时候，最容易出问题的其实是接口规范。在项目一开始就要定好统一返回体，否则后端返回String、返回Map、返回Object，前端处理逻辑会乱成一团。我当时定义了一个简单的泛型类：
@Data public class Result<T> { private Integer code; // 200成功，500失败，401未登录 private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }再配合一个全局异常处理器（@RestControllerAdvice），把校验异常、业务异常、未知异常统一拦截，返回给前端固定格式的错误信息。这套机制写完之后，前后端开发基本可以并行推进，不需要反复拉扯。
全局配置里还必须处理跨域问题。在SpringBoot中加一个配置类：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }这里注意一个细节：allowCredentials(true)和allowedOriginPatterns("*")要配合使用，如果直接用allowedOrigins("*")在早期Spring版本里会冲突。这类小坑写出来，能让看到文章的人少走很多弯路。
3. 需求梳理与数据库设计——整个项目最关键的一步
很多同学拿到题目就急着敲代码，这是本末倒置。管理信息系统类项目的核心价值其实有一半以上体现在数据库设计上。表设计得合理，后面所有业务逻辑都顺；表设计有硬伤，写代码的时候就会反复打补丁。
3.1 角色与业务场景梳理
校医院管理平台我先列了四个角色：
- 系统管理员：维护科室信息、药品字典、医生排班、账号分配、数据统计。
- 校医（医生）：查看当日挂号患者、填写诊断结果、开处方单、查看历史就诊记录。
- 药房/收费人员：处理处方划价、药品发药、入库入库审核、库存管理。
- 患者（学生/教职工）：注册登录、预约挂号、查看就诊记录、预约体检、查看体检报告。
这四个角色之间的数据流大致是这样的：患者预约挂号 → 生成挂号记录 → 医生看到待诊列表 → 接诊并填写病历 → 开出药品处方 → 药房人员确认发药并扣减库存 → 相关费用记录落库。
3.2 核心表结构
根据上面的流程，我列出了这样一组核心表：
| 表名 | 用途 | 关键字段 |
|---|---|---|
| sys_user | 系统用户表（所有角色共用） | username, password, real_name, role_id, dept_id |
| sys_role | 角色表 | role_code, role_name |
| doctor_info | 医生扩展信息表 | user_id, title, department_id, introduction |
| department | 科室表 | dept_name, description |
| patient_info | 患者信息表 | user_id, student_no, id_card, phone, type |
| schedule | 排班表 | doctor_id, dept_id, work_date, time_slot, max_count, remain_count |
| registration | 挂号记录表 | patient_id, schedule_id, status, create_time, fee |
| medical_record | 就诊记录表 | patient_id, doctor_id, diagnosis, advice, create_time |
| prescription | 处方主表 | record_id, total_amount, status, create_time |
| prescription_item | 处方明细表 | prescription_id, drug_id, quantity, unit_price, dosage |
| drug_info | 药品信息表 | drug_name, spec, unit, stock, warning_line, sale_price |
| drug_stock_log | 药品出入库记录表 | drug_id, change_type, change_count, operator_id, create_time |
| physical_exam_package | 体检套餐表 | package_name, price, items, description |
| physical_exam_order | 体检预约单表 | patient_id, package_id, order_date, status, report_path |
表之间如何关联，我用几个典型案例说明。
预约挂号模块：registration表通过schedule_id关联schedule排班表。排班表里有max_count（可预约上限）和remain_count（剩余可预约数），每次成功预约后remain_count减1。这里就必须考虑一个并发问题：如果两个学生同时预约同一个医生的最后一个号，后端的处理顺序是怎样的？后面实现部分细说，但你能看出这个字段设计就是为了承载这样的业务逻辑。
处方与药品库存：处方主表prescription通过record_id关联就诊记录，明细表prescription_item通过prescription_id关联主表保存具体药品和数量。药房发药时，会根据明细逐条扣减drug_info表的stock，并且写入drug_stock_log流水表。一条药品出入库记录必须是可追溯的：什么时间、谁操作、变动了多少数量。
3.3 数据库设计时最容易犯的错
我在很多同学的项目里看到过一个共性问题：为了省事，把多个角色信息塞进一张表，或者干脆把医生和患者的扩展字段全部堆在user表里。这种做法短期能跑，但等做权限的时候就会很难受。医生的title、患者的student_no，这些都是职责不同的字段，放在一起会让查询逻辑变得难以维护。
另一个问题是不注意字段类型和长度的合理性。手机号存varchar(11)，身份证号必须用varchar(18)而不是bigint，否则前导零会丢。学生学号也是同理，必须用字符串类型。金额字段用decimal(10,2)，不要用float或double，不然计算时会出现0.1+0.2不等于0.3的尴尬问题。
时间字段的统一也要重视。我建议所有表都用datetime存业务时间，用timestamp存记录的创建和更新时间。数据库层面设置DEFAULT CURRENT_TIMESTAMP，配合MyBatis-Plus的自动填充功能，就不会出现前端展示时间不一致的乱象。
4. 核心功能实现：从登录到就诊的全链路打通
4.1 登录认证与权限控制的落地方式
登录接口本身不复杂，就是核对用户名密码。复杂度在密码安全和权限控制两个点。
密码存储必须用加密算法。简单信息摘要算法（比如MD5）已经被认为不够安全，应该用BCryptPasswordEncoder来做哈希。Spring Security包里自带这个类，即使不引入完整的Spring Security，也可以单独拿它来做密码加密。我在项目里是这样用的：
@Service public class AuthService { @Autowired private SysUserMapper sysUserMapper; @Autowired private StringRedisTemplate redisTemplate; public Result<LoginResponse> login(LoginRequest request) { SysUser user = sysUserMapper.selectOne( new LambdaQueryWrapper<SysUser>() .eq(SysUser::getUsername, request.getUsername())); if (user == null) { return Result.error("用户名或密码错误"); } BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(); if (!encoder.matches(request.getPassword(), user.getPassword())) { return Result.error("用户名或密码错误"); } String token = JwtUtil.generateToken(user.getId(), user.getUsername(), user.getRoleId()); // 存入Redis，设置过期时间2小时 redisTemplate.opsForValue().set( "login:token:" + user.getId(), token, 2, TimeUnit.HOURS); // 返回登录结果 LoginResponse response = new LoginResponse(); response.setToken(token); response.setRoleId(user.getRoleId()); response.setRealName(user.getRealName()); return Result.success(response); } }权限控制部分，我采取的是拦截器 + 注解权限码的方式。写一个AuthInterceptor，在preHandle里解析请求头中的JWT，校验Redis中是否存在，把用户信息存入ThreadLocal。然后为每个接口定义需要的权限码，在拦截器中比对当前用户角色是否拥有对应权限。
比如，只有具有"医生"角色的账号才能访问/api/doctor/**接口，只有"管理员"才能访问/api/admin/**接口。这样写的好处是权限判断逻辑集中，新增一个接口时只需要加上注解，不用重复编写判断代码。
这里有一个我在实测中发现的细节：请求接口时前端必须先经过预检请求（OPTIONS），预检请求是不带Authorization头的。如果你在拦截器里对OPTIONS请求直接拒绝，前端会一直报跨域错误，而真正的接口却根本没执行到。所以拦截器里必须加一行判断：
if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; }这个坑，几乎每个做前后端分离的同学都会踩一次。提前写出来省得大家反复排查。
4.2 预约挂号模块的并发控制
预约挂号表面上是简单的插入一条registration记录，但内里藏着两个必须处理的问题：并发超卖和重复预约。
并发超卖指的是当remain_count只剩1个号时，两个用户同时发起预约，两个请求都读到remain_count=1，都判断"还有号"，然后都执行insert和update，最后超卖。解决办法很多，但从这个项目的复杂度出发，我推荐用数据库乐观锁的思路：
执行更新排班表剩余号源时，带上条件判断：
int updated = scheduleMapper.update( null, new LambdaUpdateWrapper<Schedule>() .eq(Schedule::getId, scheduleId) .gt(Schedule::getRemainCount, 0) .setSql("remain_count = remain_count - 1")); if (updated == 0) { throw new BusinessException("该时段号源已被抢完，请选择其他时间段"); }这段SQL的含义是：只有当剩余数量大于0时，才执行减1操作。数据库层面保证了原子性，两个并发请求最终只会有一个成功执行update，另一个更新行数为0，直接抛出"已被抢完"的提示。这样的实现简洁可靠，不需要引入分布式锁那么重的方案。
重复预约的防护则是靠加唯一索引或者业务查询判断。我在registration表上添加了一个唯一索引uk_patient_schedule（patient_id+schedule_id），数据库层面就是不允许同一个人对同一个排班记录重复挂号。即使出现极端情况两个请求同时进来，也只有一个能插入成功，另一个会报唯一键冲突，捕获这个异常转成友好的提示即可。
4.3 医生接诊与处方流转的实现要点
医生接诊的核心操作是：查看待诊列表 → 选择患者 → 填写病历 → 开处方药品。
这里最难的是处方保存时的事务一致性。因为一张处方涉及三张表的写入：medical_record（就诊记录）、prescription（处方主表）、prescription_item（处方明细表）。任何一步失败，都必须整体回滚，否则会出现就诊记录写了但处方没写，或者主表有单明细却丢失的情况。
所以这个方法上必须加@Transactional：
@Transactional(rollbackFor = Exception.class) public Long createPrescription(PrescriptionCreateRequest request) { // 1. 插入就诊记录 MedicalRecord record = new MedicalRecord(); record.setPatientId(request.getPatientId()); record.setDoctorId(CurrentUser.get().getUserId()); record.setDiagnosis(request.getDiagnosis()); record.setAdvice(request.getAdvice()); medicalRecordMapper.insert(record); // 2. 插入处方主表 Prescription prescription = new Prescription(); prescription.setRecordId(record.getId()); prescription.setStatus(0); // 0待划价, 1已发药 prescriptionMapper.insert(prescription); // 3. 遍历药品，计算总价，插入明细 BigDecimal total = BigDecimal.ZERO; for (PrescriptionItemDTO item : request.getItems()) { DrugInfo drug = drugInfoMapper.selectById(item.getDrugId()); if (drug == null || drug.getStock() < item.getQuantity()) { throw new BusinessException("药品库存不足：" + drugName); } PrescriptionItem prescriptionItem = new PrescriptionItem(); prescriptionItem.setPrescriptionId(prescription.getId()); prescriptionItem.setDrugId(drug.getId()); prescriptionItem.setQuantity(item.getQuantity()); prescriptionItem.setUnitPrice(drug.getSalePrice()); prescriptionMapper.insertItem(prescriptionItem); // 扣减库存（同样用乐观锁方式） // ... total = total.add(drug.getSalePrice().multiply(BigDecimal.valueOf(item.getQuantity()))); } prescription.setTotalAmount(total); prescriptionMapper.updateById(prescription); return prescription.getId(); }这里要说明一点：@Transactional加上之后，方法内部如果抛出了RuntimeException会回滚，但如果写的是catch (Exception e)然后吞掉不抛，事务是不会回滚的。有些同学为了前端友好，把异常捕获了却忘了重新抛出，结果数据出现半截写入。正确写法是捕获异常后记录日志，然后重新抛出，或者直接不捕获，让全局异常处理器统一处理。
4.4 药品库存模块与低库存预警
药品管理模块比较容易做成普通的增删改查，但既然有库存字段，就应该把"库存预警"这个业务动作做出来。
我的思路是：药品表里有一个warning_line（预警阈值）字段。当药品被扣减后，如果stock < warning_line，就往预警消息表里写一条记录，管理员登录时在首页看到预警列表。实现方式可以是在药品变更的Service层统一封装一个changeDrugStock()方法，所有库存变动都走这个方法，方法内部先改库存、再写流水、最后判断是否需要预警。
public synchronized void changeDrugStock(Long drugId, int changeCount, String type, Long operatorId) { DrugInfo drug = drugInfoMapper.selectById(drugId); if (drug == null) { throw new BusinessException("药品不存在"); } if (drug.getStock() + changeCount < 0) { throw new BusinessException("药品库存不足"); } drug.setStock(drug.getStock() + changeCount); drugInfoMapper.updateById(drug); DrugStockLog log = new DrugStockLog(); log.setDrugId(drugId); log.setChangeType(type); // IN-入库 OUT-出库 log.setChangeCount(Math.abs(changeCount)); log.setOperatorId(operatorId); drugStockLogMapper.insert(log); if (drug.getStock() < drug.getWarningLine()) { // 写入预警 DrugWarning warning = new DrugWarning(); warning.setDrugId(drugId); warning.setStock(drug.getStock()); warning.setWarningLine(drug.getWarningLine()); drugWarningMapper.insert(warning); } }这个changeDrugStock方法就是库存模块的统一阀门，所有出入库动作都必须经过它，不许在别的地方直接updateById去改库存。像这种"统一封装业务动作"的思路，能让代码结构清晰很多，也方便以后加日志、加预警、加审计。
4.5 体检预约与报告管理的可扩展思路
体检预约这个模块，我不建议做得太重，但应该体现出业务上的完整性。学生（患者）选择体检套餐 → 选择体检日期 → 生成预约单 → 管理员安排体检 → 上传体检报告PDF → 患者在个人中心查看报告。
关键点在于文件存储。很多毕设项目喜欢把文件二进制直接存进数据库的blob字段，或者传到服务器本地目录。这两种方式都有问题：blob会让数据库体积膨胀且查询缓慢；本地路径在项目重新部署或换服务器时会失效。更合理的方案是用MinIO或阿里云OSS做对象存储，数据库里只保存一个URL路径。
MinIO是开源的，可以作为独立服务部署在本地，代码集成成本也不高。在SpringBoot里配置好连接信息，上传接口拿到文件流后存入MinIO，返回文件路径：
@PostMapping("/upload") public Result<String> uploadReport(@RequestParam("file") MultipartFile file) { String objectKey = "exam-report/" + UUID.randomUUID() + "." + getFileExtension(file.getOriginalFilename()); minioClient.putObject(PutObjectArgs.builder() .bucket("hospital") .object(objectKey) .stream(file.getInputStream(), file.getSize(), -1) .contentType(file.getContentType()) .build()); return Result.success("http://localhost:9000/hospital/" + objectKey); }这件事在毕设里属于加分项。答辩的时候如果被问到"如果体检报告文件很大，怎么保证系统性能"，你就可以从容地讲"我采用的是对象存储，数据库只存索引，读写压力都在对象存储端"，几句话就能让老师明白你有工程实践意识。
5. 开发效率技巧与实测踩坑记录
5.1 用代码生成器快速搭建CRUD骨架
我一再强调MyBatis-Plus的代码生成器值得优先配置好。一个合理的用法是：先设计好数据库表，然后用生成工具把所有表的实体类、Mapper、Service、Controller一次性生成，再逐个调整。
生成后的实际效果：
- 实体类：字段与表字段对应，自动带
@TableName和@TableId注解。 - Mapper：直接继承
BaseMapper<T>，基础增删改查不需要写一行SQL。 - Service：继承
IService<T>，基础的列表、分页、单条查询方法都有了。
剩下的工作就是把自动生成的空壳Controller替换成真正的业务逻辑。这比从零手写每张表的CRUD，能省出将近一周的时间。
5.2 驼峰命名映射和时区这两个经典坑
驼峰映射问题：数据库字段通常用下划线命名（create_time、remain_count），Java实体类用驼峰（createTime、remainCount）。MyBatis-Plus默认开启了map-underscore-to-camel-case，所以不需要额外配置。但如果你使用了原生MyBatis的XML，在写resultMap时就得手动设置映射关系，别想当然地以为框架会自动完成。
时区问题：连接MySQL时，JDBC URL最好显式指定serverTimezone=Asia/Shanghai：
jdbc:mysql://localhost:3306/school_hospital?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8如果不指定，很多环境下默认是UTC时区。上海时间比UTC快8小时，你插入一条挂号记录显示的时间会整整少8个小时，前后端调试时很容易被绕进去，以为是前端格式化不对，其实是数据源就错了。
5.3 避免N+1查询的实践
管理系统的列表页最容易出现N+1问题。比如管理员查看药品出入库流水列表，最直观的做法是循环里逐条查询操作人姓名——每查一条流水就多一次SQL，如果一页20条记录，就是1+20次查询。
正确的思路是批量查询然后内存组装。先把流水列表查出来，收集所有operatorId去重，然后一次性selectBatchIds查出用户信息转成Map，随后在代码里遍历流水列表并填充姓名。同样的思路也适用于挂号列表展示患者姓名、医生姓名。这个优化在数据量小的时候感受不到差异，但答辩时能主动讲出"我做了N+1查询优化"，说明你是真的考虑过性能问题。
5.4 部署上线前的最终检查清单
毕业设计的演示环节，最怕的就是现场翻车。我总结过一份部署前检查清单，照着逐项确认能省掉大量麻烦：
- 数据库脚本：准备好完整的建库建表脚本和初始数据SQL。初始数据里必须有几个测试账号、一些药品数据和排班数据，否则演示时界面上空空如也，没法展示功能。
- 配置文件外置：把数据库连接、Redis连接、MinIO连接等敏感配置放在
application-prod.yml里，启动时通过--spring.profiles.active=prod指定。不要在代码里写死任何环境相关参数。 - 后端打包：使用
mvn clean package -DskipTests打成可执行Jar包。注意确认pom.xml里打包插件是spring-boot-maven-plugin，否则打出来的Jar不能直接运行。 - 前端构建：Vue项目执行
npm run build生成dist目录，用Nginx托管，并配置反向代理把/api前缀转发到后端服务端口。 - 服务器放行端口：如果用的是云服务器，记得在安全组里放行后端端口（比如8080）和Nginx端口（80或自定义端口）。
- 预演两遍：至少在正式答辩前一天，用真机完整走一遍演示流程：学生注册 → 登录 → 预约挂号 → 医生接诊 → 开处方 → 药房发药 → 患者查看记录。发现问题还有时间修补。
这些看起来都是琐事，但恰恰是这些琐事决定了答辩现场能不能顺畅跑完三分钟演示。我见过不止一个项目功能写得挺好，但因为部署时端口没放行或者Nginx配置写错，当场白屏，遗憾得很。
6. 论文结构安排与答辩准备的一些建议
毕设不只是代码，论文占了不小的分值比例。校医院平台这个题目的论文结构我建议这样组织：
- 选题背景与意义：高校扩招背景下校医院信息化需求增长，传统手工模式效率低、易出错。
- 需求分析：通过用例图来描述四种角色的功能需求，用业务流程图描述预约就诊流程。
- 系统设计：包含总体架构图（前后端分离结构）、功能模块设计、数据库ER图和表结构说明。
- 系统实现：按模块逐一展示关键功能截图和核心代码片段，对代码做简短说明。
- 系统测试：列出功能测试用例表，包括测试步骤、预期结果、实际结果。至少覆盖登录、挂号、开方、药品库存等核心场景。
答辩准备上，有四个问题被问到的概率极高，建议提前把答案背熟：
- 为什么选JWT不用Session？——因为项目是前后端分离架构，Session不便于跨域携带和维护；JWT无状态、可扩展，配合Redis可以服务端控制过期。
- 预约挂号怎么防止同一个号被抢两次？——数据库乐观锁和唯一索引双保险。乐观锁保证库存不超卖，唯一索引保证同一患者不重复预约。
- 如何设计数据库以及为什么这样设计？——从业务角度讲1对多、多对多关系如何转换为表，为什么把处方设计成主表和明细表两张，为什么药品库存要加流水日志。
- 系统存在哪些不足和可改进之处？——可以说当前未实现完整的消息通知功能，后续可以接入WebSocket或短信服务；也可以说数据统计分析还比较基础，后续可以考虑用ECharts做可视化大屏。
最后再分享一个我在实际做这个项目时的体会。选题时大家都想做"看起来高级"的东西，但真正让人拿到高分的，往往是那些把基础的事情做到极致、每个细节都能讲清楚来龙去脉的项目。校医院管理平台这个题目，表面上是经典的CRUD类系统，但当你把并发控制、事务一致性、权限设计、库存流水、对象存储这些点一个个落实的时候，整个项目就已经是远超"增删改查"的存在了。答辩时你只需要把这些设计决策的逻辑讲出来，老师自然会明白你的工程量和技术理解到了什么水平。如果时间允许，我建议在此基础上再加一个统计分析模块，用后端定时任务统计每天的门诊量、科室接诊分布、药品消耗排行，后端提供数据接口，前端用柱状图和饼图呈现。这个模块写起来不难，但会让整个系统从"能用"提升到"好看"，展示效果会明显上一个台阶。
