我最早接触“眼科患者随访管理系统”这个选题是在帮几个做毕业设计的学弟梳理开题方向的时候。他们普遍遇到一个尴尬纯做增删改查的“XX管理系统”太单薄咬着牙上微服务又hold不住而“眼科随访”恰好卡在中间——业务逻辑有得写、技术栈刚好覆盖JavaSpringBootSSM的老牌组合演示效果也直观。今天这篇就完整拆一遍这套系统的设计思路和落地细节重点讲清楚为什么用这个技术组合、核心模块怎么建模、启动调试时哪些坑最容易把人卡死。适合正在做类似医疗管理类课设/毕设的同学也适合刚入职想快速上手SpringBootSSM工程的初级开发参考。1. 眼科随访系统到底要解决什么业务问题很多同学拿到这类题目第一反应是“不就是患者信息的增删改查吗”如果你也这么想后面肯定会被导师问住。医疗随访系统的本质是持续追踪患者术后/院后状态它关注的不是“某个时刻的病历”而是“一段时间的康复曲线”。眼科尤其典型白内障术后要定期查眼压、青光眼患者要监测视野变化、角膜移植要跟踪排斥反应这些都不是一次就诊能解决的。1.1 从模糊需求到功能清单的拆解过程题目里的“眼科患者随访管理”落到系统里至少要拆出这几条业务线患者全生命周期档案基本信息、诊断信息、手术记录、过敏史这部分是主数据的根基。随访计划引擎不同病种有不同随访频率术后1周、1个月、3个月、半年系统要能按规则自动生成随访计划而不是靠护士手工翻台账。随访执行与记录电话随访、复诊随访、线上问卷三种方式每次随访要记录视力、眼压、症状变化等专科指标还要能对比历次数据。异常预警与提醒眼压超过阈值、视力持续下降系统要自动标红提醒医生介入。统计报表科室想知道“本月青光眼患者随访依从率是多少”“失访原因分布”这需要多维度的统计查询。如果这些功能全靠人工一个负责随访的护士每天要打几十通电话、翻几十本纸质档案效率极低还容易漏人。系统要解决的痛点就是把“什么时候该随访谁”这件事从人脑记忆变成系统自动触发把零散的随访记录变成结构化数据。明白了业务诉求后续的表结构设计、接口划分才有依据而不是上来就写代码。1.2 技术选型为什么是JavaSpringBootSSM而不是别的按现在的主流趋势新项目很多直接上SpringBootMyBatis-Plus甚至微服务。但放在课设/毕设语境里SpringBootSSM的组合仍然是最稳的选择原因有三架构层次清晰好写文档好画图SSMSpringSpringMVCMyBatis分层是Controller-Service-Mapper的标准三层画系统架构图、写详细设计说明时每一层职责一目了然答辩时能够说得清楚。SpringBoot负责“解放配置”、SSM负责“规范结构”SpringBoot把Tomcat内置、自动装配这些脏活都处理掉了同时你保留了SpringMVC的请求映射方式和MyBatis的SQL控制力相当于既有开发效率又没丢掉底层掌控感。匹配市面上绝大多数参考文献知网里大量医疗管理系统的设计与实现论文都是这套组合查资料、借鉴表设计都方便。补充说明一下如果你用SpringBoot整合SSM本质上是“SpringBoot作为容器引入SpringMVC和MyBatis依赖”。它和传统SSM项目SSM外部Tomcat war包部署的区别仅在于启动方式和配置方式代码内核一模一样。我这个项目用的是SpringBoot 2.x内嵌Tomcat MyBatis SpringMVC后续为了便于讲解依然按“SpringBootSSM”这个叫法统一表述。2. 核心业务链路与数据库模型设计要点数据库设计是这类项目最花时间也最容易被扣分的地方。眼科随访系统的表结构不能照搬通用erp必须针对“随访计划生成”“随访指标对比”“依从性统计”这三个特性来设计。2.1 病种模板表让随访规则可配置我不建议直接在代码里硬编码“白内障术后1周随访”这类规则而是使用病种随访模板表disease_template来存规则CREATE TABLE disease_template ( id INT PRIMARY KEY AUTO_INCREMENT, disease_type VARCHAR(50) COMMENT 病种类型白内障/青光眼/角膜移植等, node_name VARCHAR(100) COMMENT 随访节点名称如术后1周、术后1个月, follow_days INT COMMENT 距手术/上次随访多少天, follow_cycle INT COMMENT 随访周期天数用于周期性随访, indicator_ids VARCHAR(255) COMMENT 需要记录的指标id集合如视力、眼压, template_status TINYINT COMMENT 是否启用, create_time DATETIME );这张表的价值在于不同病种对应不同随访规则将来医院想调整随访频率改数据库就行不用改代码。访计划生成时系统加载该病种所有启用状态的模板用“手术日期/上次随访日期 follow_days”算出下一次随访日期自动写入随访计划表。2.2 随访计划与执行记录的分表设计业务上要区分“计划”和“执行”计划是系统自动生成的待办事项执行是护士/医生实际完成的随访结果。两件事不分开统计“随访率”的时候就会混乱——随访率的分母是应随访次数分子是实际完成次数而“应随访”只能来自计划表。我建了follow_plan和follow_record两张表follow_plan患者ID、计划随访日期、计划节点名称、计划状态待执行/已完成/已逾期、关联的病种模板ID。follow_record计划ID、随访方式电话/门诊/问卷、随访日期、实际随访人、主观症状描述、眼压值、视力值等专科指标、结论好转/稳定/恶化、下次随访建议。这样设计之后follow_record通过plan_id关联follow_plan每次随访都指向最初生成的计划追溯链路完整统计报表也只需要做表和表之间的关联查询。2.3 眼科专科指标的字段取舍眼科患者的随访指标非常专科化视力左右眼分开、眼压、前房反应、角膜内皮细胞计数等。如果都建成一个个独立字段表会非常臃肿且难以扩展。我采用的方案是核心且高频的指标做成固定字段vision_left、vision_right、iop_left眼压、iop_right。其余低频指标用JSON字段存储extra_indicator_json里面放键值对。MySQL 5.7以上支持JSON类型查询时用json_extract也可以检索。这样既保证了核心指标能被系统用于预警判断比如眼压21mmHg自动预警又给未来扩展留了口子。答辩时这段设计思路讲出来技术分提升明显。3. 工程结构落地SpringBoot与SSM分层如何无缝配合确定了业务模型接下来是把工程搭起来。这里有一个很多教程含糊带过的关键点SpringBoot项目里如何正确让SpringMVC和MyBatis各司其职。3.1 依赖引入与版本搭配我用SpringBoot 2.3.12.RELEASE注意不要用3.xMyBatis的starter对3.x兼容度还不太好配套mybatis-spring-boot-starter2.1.4MySQL驱动8.0.xDruid连接池1.2.6。核心依赖如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.1.4/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.23/version scoperuntime/scope /dependency dependency groupIdcom.alibaba/groupId artifactIddruid-spring-boot-starter/artifactId version1.2.6/version /dependency这里强调版本不是凑字数。我见过太多人卡在启动阶段报Property sqlSessionFactory or SqlSessionTemplate are required十有八九是SpringBoot版本和mybatis-starter版本不匹配导致的自动配置失败。用上面这套组合实测可以一路跑通。3.2 application.yml配置的核心参数配置文件里除了常规的数据源配置有四个参数特别关键mybatis.mapper-locations指定XML文件位置记得配成classpath:mapper/*.xml。mybatis.type-aliases-package实体类包路径让MyBatis自动注册别名XML里就不用写全限定类名。spring.datasource.druid.initial-size初始连接数建议8最大活跃数建议20太小了并发查询会排队。server.servlet.context-path统一加/eye前缀后面写前端页面时路径更清晰。一个容易忽略的细节是SpringBoot 2.x默认用HikariCP你引入了druid-spring-boot-starter之后如果yml里还写着spring.datasource.hikari.*两者会冲突。正确写法是直接使用spring.datasource.druid.*前缀让Druid配置生效。3.3 Mapper层踩坑XML里的空格和resultMap对齐问题MyBatis的XML写起来不算难但两个细节坑过我很多次第一XML中if test...条件判断里的字符串比较一定写成teststatus 1.toString()或者test1.equals(status)直接写teststatus1有时候会报数字格式异常尤其当字段是Integer类型时。第二查询结果映射建议显式写resultMap而不是直接resultTypeHashMap。因为后续要做Excel导出字段名必须是规范的驼峰风格如果用HashMap查出来的create_time这种下划线字段不会自动转驼峰导出时还得再手动处理一遍。4. 随访计划生成与自动提醒的代码实现这一部分是整个系统的技术亮点。我重点讲两个功能随访计划的自动生成、基于定时任务的到期提醒。4.1 随访计划生成使用Spring的Scheduled实现定时扫描思路很直接每天凌晨1点系统扫描所有已登记患者结合disease_template表生成未来30天的随访计划。核心逻辑放在Service层Service public class FollowPlanGenerateService { Autowired private DiseaseTemplateMapper templateMapper; Autowired private PatientMapper patientMapper; Autowired private FollowPlanMapper planMapper; Scheduled(cron 0 0 1 * * ?) public void generateDailyPlan() { ListDiseaseTemplate templates templateMapper.selectEnabledTemplates(); ListPatient patients patientMapper.selectAllValidPatients(); for (Patient patient : patients) { for (DiseaseTemplate template : templates) { if (!template.getDiseaseType().equals(patient.getDiseaseType())) { continue; } Date nextFollowDate calcNextFollowDate(patient, template); if (isWithin30Days(nextFollowDate)) { saveIfNotExists(patient.getId(), template, nextFollowDate); } } } } private Date calcNextFollowDate(Patient patient, DiseaseTemplate template) { Date baseDate patient.getSurgeryDate() ! null ? patient.getSurgeryDate() : patient.getCreateTime(); Date lastPlan planMapper.selectMaxPlanDate(patient.getId(), template.getId()); if (lastPlan ! null) { baseDate lastPlan; } Calendar calendar Calendar.getInstance(); calendar.setTime(baseDate); calendar.add(Calendar.DAY_OF_MONTH, template.getFollowDays()); return calendar.getTime(); } }这段代码的逻辑解释一下saveIfNotExists会先查一下是否已存在相同患者、相同模板、相同随访日期的记录防止定时任务重复执行产生脏数据这也是医疗数据管理的基本功——幂等性。有没有听过“定时任务重复执行导致患者被随访两次”的事故真实场景里确实出现过所以幂等判断必须写。4.2 到期提醒整合微信/短信的冗余方案计划生成后执行端需要感知“今天该随访谁”。我做了两层提醒站内待办医生/护士登录系统后工作台直接展示今天待随访列表按照患者姓名、病种、紧急程度排序。自动短信提醒可选扩展给患者发提醒短信。短信服务商选择上阿里云、腾讯云都行但注意一点——测试阶段别真发短信我在代码里留了一个开关remind.switchtrue/false关闭时只打印日志方便本地演示。提醒内容的模板我用String.format拼装比如“尊敬的%s您于%s在我院接受%s手术近期需复查随访请合理安排时间。” 格式化参数依次是患者姓名、手术日期、病种名称。4.3 随访问卷评分一个现实可落地的算法逻辑除了电话随访系统还要支持问卷调查。眼科的常用问卷之一是“干眼症调查问卷OSDI”一共12个问题每个问题0~4分。问卷评分的核心是维度统计public Double calcOsdiScore(ListInteger answers) { if (answers null || answers.isEmpty()) { return 0.0; } int sum answers.stream().mapToInt(Integer::intValue).sum(); int questionCount answers.size(); double rawScore sum * 25.0 / (questionCount * 4.0); return BigDecimal.valueOf(rawScore).setScale(1, RoundingMode.HALF_UP).doubleValue(); }这里有一个细节OSDI的原始分区间是0~100分但公式不是直接求平均而是sum * 25 / (答题数 * 4)因为每个问题满分4分、总共12题时总分48分换算成百分制就要乘以25/48。如果你直接把12个问题的分数求平均结果会有偏差。这种专科评分逻辑写对说明你对业务理解到位答辩的时候考官很难问倒。5. 权限控制与前端联动一个工程级的拦截器设计医疗系统涉及患者隐私权限控制不能是摆设。SpringBootSSM结合Shiro或者Spring Security都能做但课设项目里自己写拦截器反而更好理解、也更容易讲清楚。5.1 自定义HandlerInterceptor实现登录校验与角色鉴权我的方案是基于Session拦截器做两层校验。第一层校验是否登录第二层校验角色权限public class AuthInterceptor implements HandlerInterceptor { Autowired private RedisTemplateString, Object redisTemplate; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 if (request.getRequestURI().contains(/login) || request.getRequestURI().contains(/captcha)) { return true; } HttpSession session request.getSession(); User user (User) session.getAttribute(loginUser); if (user null) { response.sendRedirect(/eye/login.html); return false; } // 角色校验只有ADMIN/DOCTOR角色能访问患者管理接口 String uri request.getRequestURI(); if (uri.contains(/patient) !(ADMIN.equals(user.getRole()) || DOCTOR.equals(user.getRole()))) { response.setStatus(HttpServletResponse.SC_FORBIDDEN); return false; } return true; } }注意我在拦截器里用的是URI片段匹配而不是精确路径匹配好处是/patient/list、/patient/detail/{id}这些同前缀接口都能被统一拦截扩展新接口时不用改拦截规则。注册拦截器时离不开WebMvcConfigurerConfiguration public class WebMvcConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/**) .excludePathPatterns(/login, /captcha, /css/**, /js/**, /images/**); } }这里最容易被忽略的是静态资源排除。如果你忘了排除/css/**、/js/**页面加载时会发现样式全丢了——因为拦截器把所有静态资源请求也拦下来了重定向到登录页就导致样式404。我最早自己写这个功能时排查了整整一个下午才反应过来。5.2 前端VueElementUI和SpringBoot接口的分页协定前端如果用了VueElementUI后端的接口设计需要定好统一返回值格式。我在项目里封装了ResultT类public class ResultT { private Integer code; private String message; private T data; private Long total; public static T ResultT ok(T data, Long total) { ResultT r new Result(); r.code 200; r.message 操作成功; r.data data; r.total total; return r; } }前端分页组件用el-pagination时current-page对应当前页码、page-size对应每页条数后端接口接收pageNum和pageSize返回Result里的data是当前页数据列表、total是总记录数。这个约定要写进接口文档里前后端各写各的就很容易出现“前端拿不到total导致分页不显示”的尴尬。分页SQL用MyBatis的PageHelper或者手写LIMIT #{offset}, #{pageSize}都行。我建议手写因为PageHelper的Page对象侵入性较强偶尔会出现SqlSession关闭异常这种奇怪问题手写更可控。6. 调试启动阶段的常见错误与排查链路这部分是省时间的核心——我把自己调试过程中的问题按“症状—原因—解决”整理成表遇到类似报错直接查表定位。6.1 环境准备与工程启动前的版本核对启动前请先确认组件推荐版本说明JDK1.8SpringBoot 2.x对JDK17有兼容问题建议直接用JDK8MySQL5.7/8.05.7的JSON类型不如8.0好用建议8.0Maven3.63.8也没问题Node.js前端14如果前端是Vue项目Node版本太高会报OpenSSL错误JDK8这一点要特别强调很多新电脑默认装了JDK17或21SpringBoot 2.3.12在JDK17上会报Unable to make protected native java.lang.Object nativeClone() accessible反射错误。解决方案要么换JDK8要么升级SpringBoot 2.7但升级版本可能连带MyBatis版本也要动所以不如直接装JDK8省心。6.2 数据库连接与Mapper扫描时报错的排查顺序错误一Invalid bound statement (not found): com.xxx.mapper.PatientMapper.selectPage这是MyBatis最常见的错误90%是因为XML文件里的namespace或方法id对不上或者XML文件没被扫描到。排查顺序先看application.yml里的mapper-locations路径与实际XML所在目录是否一致。常见错误是写classpath:mapper/*.xml但XML放在了resources/mapper之外的目录。打开XML文件看namespace是否为接口的全限定名。确认接口方法名和XML里的id完全一致包括大小写。错误二Access denied for user rootlocalhost这个往往不是密码错误而是MySQL8.0默认用了caching_sha2_password认证插件而druid连接池1.2.6对它的兼容性不太好。解决方案是创建用户时指定mysql_native_passwordCREATE USER eye_user% IDENTIFIED WITH mysql_native_password BY yourpassword; GRANT ALL PRIVILEGES ON eye_followup.* TO eye_user%; FLUSH PRIVILEGES;6.3 调试利器内置一个可视化的SQL日志输出application.yml里加这段配置控制台就能打印完整SQL和参数logging: level: com.example.eyefollow: debug mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl注意logging.level后面要跟你的Mapper接口所在的包全路径而不是Mapper层写debug就行。我见过有人配了logging.level.root: debug结果整个项目的日志刷屏反而找不到需要的SQL。把SQL日志打开再配合排查大部分业务查询问题都能快速定位是SQL写错了、参数没传进去还是数据本身有问题一眼就能看出来。调试完记得关掉log-impl否则生产环境会输出大量日志影响性能。7. 文档配套与答辩准备的实操建议标题里带了“LW”论文/文档这块反而是很多同学容易翻车的地方。代码跑通了论文写得像流水账照样拿不到好成绩。7.1 系统架构图的画法思路画系统架构图时不要画成“前端——后端——数据库”三条直线要体现出SSM三层在工程里的真实结构。推荐这样分层展示层Vue页面或Thymeleaf模板负责交互。控制层SpringMVC的Controller负责接收请求、参数校验、返回值封装。业务层Service接口实现类负责核心业务逻辑随访计划生成、问卷评分、报表统计。持久层MyBatis的Mapper接口XML负责SQL操作。架构图里还要画上外部依赖MySQL数据库、Druid连接池、定时任务调度器、短信服务如有。标注清楚数据流向论文里的系统设计章节就有说服力了。7.2 演示时的数据准备与场景脚本答辩现场最怕的是临时数据尴尬点开随访计划列表是空的或者随访记录全是测试数据看不出规则。我建议准备一份演示专用数据集5个不同病种类型、不同手术日期的患者覆盖白内障术后1周/1个月、青光眼定期随访等。每种病种至少3条已生成的随访计划且未来15天内要有几条待执行记录方便演示自动提醒和待办列表。2条随访记录指标数据要有明显对比比如一次眼压20、一次眼压25方便演示“异常预警”逻辑。演示顺序建议先功能截图兜底再现场跑通核心链路。哪怕现场出问题你是不是准备充分这件事评委一眼就能看出来功夫花在数据准备上比多写两个功能更划算。我个人在实际调试这个项目时最深的感觉是仿造一个“管理系统”不难真正拉开差距的是业务细节的完整度——把随访规则、评分算法、预警逻辑这些点做扎实这个项目就立住了。后续要扩展的话还能继续做患者微信端自助随访、脱敏数据的统计大屏接入Selenium做自动化验收测试每一个方向都是论文里现成的“展望与改进”素材也是面试时能和别人聊出来的增量亮点。 
长河君 · 2026/10/10 21:30:37 · 阅读 1.2k 基于SpringBoot+SSM架构的眼科患者随访管理系统设计实现
我最早接触“眼科患者随访管理系统”这个选题是在帮几个做毕业设计的学弟梳理开题方向的时候。他们普遍遇到一个尴尬纯做增删改查的“XX管理系统”太单薄咬着牙上微服务又hold不住而“眼科随访”恰好卡在中间——业务逻辑有得写、技术栈刚好覆盖JavaSpringBootSSM的老牌组合演示效果也直观。今天这篇就完整拆一遍这套系统的设计思路和落地细节重点讲清楚为什么用这个技术组合、核心模块怎么建模、启动调试时哪些坑最容易把人卡死。适合正在做类似医疗管理类课设/毕设的同学也适合刚入职想快速上手SpringBootSSM工程的初级开发参考。1. 眼科随访系统到底要解决什么业务问题很多同学拿到这类题目第一反应是“不就是患者信息的增删改查吗”如果你也这么想后面肯定会被导师问住。医疗随访系统的本质是持续追踪患者术后/院后状态它关注的不是“某个时刻的病历”而是“一段时间的康复曲线”。眼科尤其典型白内障术后要定期查眼压、青光眼患者要监测视野变化、角膜移植要跟踪排斥反应这些都不是一次就诊能解决的。1.1 从模糊需求到功能清单的拆解过程题目里的“眼科患者随访管理”落到系统里至少要拆出这几条业务线患者全生命周期档案基本信息、诊断信息、手术记录、过敏史这部分是主数据的根基。随访计划引擎不同病种有不同随访频率术后1周、1个月、3个月、半年系统要能按规则自动生成随访计划而不是靠护士手工翻台账。随访执行与记录电话随访、复诊随访、线上问卷三种方式每次随访要记录视力、眼压、症状变化等专科指标还要能对比历次数据。异常预警与提醒眼压超过阈值、视力持续下降系统要自动标红提醒医生介入。统计报表科室想知道“本月青光眼患者随访依从率是多少”“失访原因分布”这需要多维度的统计查询。如果这些功能全靠人工一个负责随访的护士每天要打几十通电话、翻几十本纸质档案效率极低还容易漏人。系统要解决的痛点就是把“什么时候该随访谁”这件事从人脑记忆变成系统自动触发把零散的随访记录变成结构化数据。明白了业务诉求后续的表结构设计、接口划分才有依据而不是上来就写代码。1.2 技术选型为什么是JavaSpringBootSSM而不是别的按现在的主流趋势新项目很多直接上SpringBootMyBatis-Plus甚至微服务。但放在课设/毕设语境里SpringBootSSM的组合仍然是最稳的选择原因有三架构层次清晰好写文档好画图SSMSpringSpringMVCMyBatis分层是Controller-Service-Mapper的标准三层画系统架构图、写详细设计说明时每一层职责一目了然答辩时能够说得清楚。SpringBoot负责“解放配置”、SSM负责“规范结构”SpringBoot把Tomcat内置、自动装配这些脏活都处理掉了同时你保留了SpringMVC的请求映射方式和MyBatis的SQL控制力相当于既有开发效率又没丢掉底层掌控感。匹配市面上绝大多数参考文献知网里大量医疗管理系统的设计与实现论文都是这套组合查资料、借鉴表设计都方便。补充说明一下如果你用SpringBoot整合SSM本质上是“SpringBoot作为容器引入SpringMVC和MyBatis依赖”。它和传统SSM项目SSM外部Tomcat war包部署的区别仅在于启动方式和配置方式代码内核一模一样。我这个项目用的是SpringBoot 2.x内嵌Tomcat MyBatis SpringMVC后续为了便于讲解依然按“SpringBootSSM”这个叫法统一表述。2. 核心业务链路与数据库模型设计要点数据库设计是这类项目最花时间也最容易被扣分的地方。眼科随访系统的表结构不能照搬通用erp必须针对“随访计划生成”“随访指标对比”“依从性统计”这三个特性来设计。2.1 病种模板表让随访规则可配置我不建议直接在代码里硬编码“白内障术后1周随访”这类规则而是使用病种随访模板表disease_template来存规则CREATE TABLE disease_template ( id INT PRIMARY KEY AUTO_INCREMENT, disease_type VARCHAR(50) COMMENT 病种类型白内障/青光眼/角膜移植等, node_name VARCHAR(100) COMMENT 随访节点名称如术后1周、术后1个月, follow_days INT COMMENT 距手术/上次随访多少天, follow_cycle INT COMMENT 随访周期天数用于周期性随访, indicator_ids VARCHAR(255) COMMENT 需要记录的指标id集合如视力、眼压, template_status TINYINT COMMENT 是否启用, create_time DATETIME );这张表的价值在于不同病种对应不同随访规则将来医院想调整随访频率改数据库就行不用改代码。访计划生成时系统加载该病种所有启用状态的模板用“手术日期/上次随访日期 follow_days”算出下一次随访日期自动写入随访计划表。2.2 随访计划与执行记录的分表设计业务上要区分“计划”和“执行”计划是系统自动生成的待办事项执行是护士/医生实际完成的随访结果。两件事不分开统计“随访率”的时候就会混乱——随访率的分母是应随访次数分子是实际完成次数而“应随访”只能来自计划表。我建了follow_plan和follow_record两张表follow_plan患者ID、计划随访日期、计划节点名称、计划状态待执行/已完成/已逾期、关联的病种模板ID。follow_record计划ID、随访方式电话/门诊/问卷、随访日期、实际随访人、主观症状描述、眼压值、视力值等专科指标、结论好转/稳定/恶化、下次随访建议。这样设计之后follow_record通过plan_id关联follow_plan每次随访都指向最初生成的计划追溯链路完整统计报表也只需要做表和表之间的关联查询。2.3 眼科专科指标的字段取舍眼科患者的随访指标非常专科化视力左右眼分开、眼压、前房反应、角膜内皮细胞计数等。如果都建成一个个独立字段表会非常臃肿且难以扩展。我采用的方案是核心且高频的指标做成固定字段vision_left、vision_right、iop_left眼压、iop_right。其余低频指标用JSON字段存储extra_indicator_json里面放键值对。MySQL 5.7以上支持JSON类型查询时用json_extract也可以检索。这样既保证了核心指标能被系统用于预警判断比如眼压21mmHg自动预警又给未来扩展留了口子。答辩时这段设计思路讲出来技术分提升明显。3. 工程结构落地SpringBoot与SSM分层如何无缝配合确定了业务模型接下来是把工程搭起来。这里有一个很多教程含糊带过的关键点SpringBoot项目里如何正确让SpringMVC和MyBatis各司其职。3.1 依赖引入与版本搭配我用SpringBoot 2.3.12.RELEASE注意不要用3.xMyBatis的starter对3.x兼容度还不太好配套mybatis-spring-boot-starter2.1.4MySQL驱动8.0.xDruid连接池1.2.6。核心依赖如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.1.4/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.23/version scoperuntime/scope /dependency dependency groupIdcom.alibaba/groupId artifactIddruid-spring-boot-starter/artifactId version1.2.6/version /dependency这里强调版本不是凑字数。我见过太多人卡在启动阶段报Property sqlSessionFactory or SqlSessionTemplate are required十有八九是SpringBoot版本和mybatis-starter版本不匹配导致的自动配置失败。用上面这套组合实测可以一路跑通。3.2 application.yml配置的核心参数配置文件里除了常规的数据源配置有四个参数特别关键mybatis.mapper-locations指定XML文件位置记得配成classpath:mapper/*.xml。mybatis.type-aliases-package实体类包路径让MyBatis自动注册别名XML里就不用写全限定类名。spring.datasource.druid.initial-size初始连接数建议8最大活跃数建议20太小了并发查询会排队。server.servlet.context-path统一加/eye前缀后面写前端页面时路径更清晰。一个容易忽略的细节是SpringBoot 2.x默认用HikariCP你引入了druid-spring-boot-starter之后如果yml里还写着spring.datasource.hikari.*两者会冲突。正确写法是直接使用spring.datasource.druid.*前缀让Druid配置生效。3.3 Mapper层踩坑XML里的空格和resultMap对齐问题MyBatis的XML写起来不算难但两个细节坑过我很多次第一XML中if test...条件判断里的字符串比较一定写成teststatus 1.toString()或者test1.equals(status)直接写teststatus1有时候会报数字格式异常尤其当字段是Integer类型时。第二查询结果映射建议显式写resultMap而不是直接resultTypeHashMap。因为后续要做Excel导出字段名必须是规范的驼峰风格如果用HashMap查出来的create_time这种下划线字段不会自动转驼峰导出时还得再手动处理一遍。4. 随访计划生成与自动提醒的代码实现这一部分是整个系统的技术亮点。我重点讲两个功能随访计划的自动生成、基于定时任务的到期提醒。4.1 随访计划生成使用Spring的Scheduled实现定时扫描思路很直接每天凌晨1点系统扫描所有已登记患者结合disease_template表生成未来30天的随访计划。核心逻辑放在Service层Service public class FollowPlanGenerateService { Autowired private DiseaseTemplateMapper templateMapper; Autowired private PatientMapper patientMapper; Autowired private FollowPlanMapper planMapper; Scheduled(cron 0 0 1 * * ?) public void generateDailyPlan() { ListDiseaseTemplate templates templateMapper.selectEnabledTemplates(); ListPatient patients patientMapper.selectAllValidPatients(); for (Patient patient : patients) { for (DiseaseTemplate template : templates) { if (!template.getDiseaseType().equals(patient.getDiseaseType())) { continue; } Date nextFollowDate calcNextFollowDate(patient, template); if (isWithin30Days(nextFollowDate)) { saveIfNotExists(patient.getId(), template, nextFollowDate); } } } } private Date calcNextFollowDate(Patient patient, DiseaseTemplate template) { Date baseDate patient.getSurgeryDate() ! null ? patient.getSurgeryDate() : patient.getCreateTime(); Date lastPlan planMapper.selectMaxPlanDate(patient.getId(), template.getId()); if (lastPlan ! null) { baseDate lastPlan; } Calendar calendar Calendar.getInstance(); calendar.setTime(baseDate); calendar.add(Calendar.DAY_OF_MONTH, template.getFollowDays()); return calendar.getTime(); } }这段代码的逻辑解释一下saveIfNotExists会先查一下是否已存在相同患者、相同模板、相同随访日期的记录防止定时任务重复执行产生脏数据这也是医疗数据管理的基本功——幂等性。有没有听过“定时任务重复执行导致患者被随访两次”的事故真实场景里确实出现过所以幂等判断必须写。4.2 到期提醒整合微信/短信的冗余方案计划生成后执行端需要感知“今天该随访谁”。我做了两层提醒站内待办医生/护士登录系统后工作台直接展示今天待随访列表按照患者姓名、病种、紧急程度排序。自动短信提醒可选扩展给患者发提醒短信。短信服务商选择上阿里云、腾讯云都行但注意一点——测试阶段别真发短信我在代码里留了一个开关remind.switchtrue/false关闭时只打印日志方便本地演示。提醒内容的模板我用String.format拼装比如“尊敬的%s您于%s在我院接受%s手术近期需复查随访请合理安排时间。” 格式化参数依次是患者姓名、手术日期、病种名称。4.3 随访问卷评分一个现实可落地的算法逻辑除了电话随访系统还要支持问卷调查。眼科的常用问卷之一是“干眼症调查问卷OSDI”一共12个问题每个问题0~4分。问卷评分的核心是维度统计public Double calcOsdiScore(ListInteger answers) { if (answers null || answers.isEmpty()) { return 0.0; } int sum answers.stream().mapToInt(Integer::intValue).sum(); int questionCount answers.size(); double rawScore sum * 25.0 / (questionCount * 4.0); return BigDecimal.valueOf(rawScore).setScale(1, RoundingMode.HALF_UP).doubleValue(); }这里有一个细节OSDI的原始分区间是0~100分但公式不是直接求平均而是sum * 25 / (答题数 * 4)因为每个问题满分4分、总共12题时总分48分换算成百分制就要乘以25/48。如果你直接把12个问题的分数求平均结果会有偏差。这种专科评分逻辑写对说明你对业务理解到位答辩的时候考官很难问倒。5. 权限控制与前端联动一个工程级的拦截器设计医疗系统涉及患者隐私权限控制不能是摆设。SpringBootSSM结合Shiro或者Spring Security都能做但课设项目里自己写拦截器反而更好理解、也更容易讲清楚。5.1 自定义HandlerInterceptor实现登录校验与角色鉴权我的方案是基于Session拦截器做两层校验。第一层校验是否登录第二层校验角色权限public class AuthInterceptor implements HandlerInterceptor { Autowired private RedisTemplateString, Object redisTemplate; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 if (request.getRequestURI().contains(/login) || request.getRequestURI().contains(/captcha)) { return true; } HttpSession session request.getSession(); User user (User) session.getAttribute(loginUser); if (user null) { response.sendRedirect(/eye/login.html); return false; } // 角色校验只有ADMIN/DOCTOR角色能访问患者管理接口 String uri request.getRequestURI(); if (uri.contains(/patient) !(ADMIN.equals(user.getRole()) || DOCTOR.equals(user.getRole()))) { response.setStatus(HttpServletResponse.SC_FORBIDDEN); return false; } return true; } }注意我在拦截器里用的是URI片段匹配而不是精确路径匹配好处是/patient/list、/patient/detail/{id}这些同前缀接口都能被统一拦截扩展新接口时不用改拦截规则。注册拦截器时离不开WebMvcConfigurerConfiguration public class WebMvcConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/**) .excludePathPatterns(/login, /captcha, /css/**, /js/**, /images/**); } }这里最容易被忽略的是静态资源排除。如果你忘了排除/css/**、/js/**页面加载时会发现样式全丢了——因为拦截器把所有静态资源请求也拦下来了重定向到登录页就导致样式404。我最早自己写这个功能时排查了整整一个下午才反应过来。5.2 前端VueElementUI和SpringBoot接口的分页协定前端如果用了VueElementUI后端的接口设计需要定好统一返回值格式。我在项目里封装了ResultT类public class ResultT { private Integer code; private String message; private T data; private Long total; public static T ResultT ok(T data, Long total) { ResultT r new Result(); r.code 200; r.message 操作成功; r.data data; r.total total; return r; } }前端分页组件用el-pagination时current-page对应当前页码、page-size对应每页条数后端接口接收pageNum和pageSize返回Result里的data是当前页数据列表、total是总记录数。这个约定要写进接口文档里前后端各写各的就很容易出现“前端拿不到total导致分页不显示”的尴尬。分页SQL用MyBatis的PageHelper或者手写LIMIT #{offset}, #{pageSize}都行。我建议手写因为PageHelper的Page对象侵入性较强偶尔会出现SqlSession关闭异常这种奇怪问题手写更可控。6. 调试启动阶段的常见错误与排查链路这部分是省时间的核心——我把自己调试过程中的问题按“症状—原因—解决”整理成表遇到类似报错直接查表定位。6.1 环境准备与工程启动前的版本核对启动前请先确认组件推荐版本说明JDK1.8SpringBoot 2.x对JDK17有兼容问题建议直接用JDK8MySQL5.7/8.05.7的JSON类型不如8.0好用建议8.0Maven3.63.8也没问题Node.js前端14如果前端是Vue项目Node版本太高会报OpenSSL错误JDK8这一点要特别强调很多新电脑默认装了JDK17或21SpringBoot 2.3.12在JDK17上会报Unable to make protected native java.lang.Object nativeClone() accessible反射错误。解决方案要么换JDK8要么升级SpringBoot 2.7但升级版本可能连带MyBatis版本也要动所以不如直接装JDK8省心。6.2 数据库连接与Mapper扫描时报错的排查顺序错误一Invalid bound statement (not found): com.xxx.mapper.PatientMapper.selectPage这是MyBatis最常见的错误90%是因为XML文件里的namespace或方法id对不上或者XML文件没被扫描到。排查顺序先看application.yml里的mapper-locations路径与实际XML所在目录是否一致。常见错误是写classpath:mapper/*.xml但XML放在了resources/mapper之外的目录。打开XML文件看namespace是否为接口的全限定名。确认接口方法名和XML里的id完全一致包括大小写。错误二Access denied for user rootlocalhost这个往往不是密码错误而是MySQL8.0默认用了caching_sha2_password认证插件而druid连接池1.2.6对它的兼容性不太好。解决方案是创建用户时指定mysql_native_passwordCREATE USER eye_user% IDENTIFIED WITH mysql_native_password BY yourpassword; GRANT ALL PRIVILEGES ON eye_followup.* TO eye_user%; FLUSH PRIVILEGES;6.3 调试利器内置一个可视化的SQL日志输出application.yml里加这段配置控制台就能打印完整SQL和参数logging: level: com.example.eyefollow: debug mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl注意logging.level后面要跟你的Mapper接口所在的包全路径而不是Mapper层写debug就行。我见过有人配了logging.level.root: debug结果整个项目的日志刷屏反而找不到需要的SQL。把SQL日志打开再配合排查大部分业务查询问题都能快速定位是SQL写错了、参数没传进去还是数据本身有问题一眼就能看出来。调试完记得关掉log-impl否则生产环境会输出大量日志影响性能。7. 文档配套与答辩准备的实操建议标题里带了“LW”论文/文档这块反而是很多同学容易翻车的地方。代码跑通了论文写得像流水账照样拿不到好成绩。7.1 系统架构图的画法思路画系统架构图时不要画成“前端——后端——数据库”三条直线要体现出SSM三层在工程里的真实结构。推荐这样分层展示层Vue页面或Thymeleaf模板负责交互。控制层SpringMVC的Controller负责接收请求、参数校验、返回值封装。业务层Service接口实现类负责核心业务逻辑随访计划生成、问卷评分、报表统计。持久层MyBatis的Mapper接口XML负责SQL操作。架构图里还要画上外部依赖MySQL数据库、Druid连接池、定时任务调度器、短信服务如有。标注清楚数据流向论文里的系统设计章节就有说服力了。7.2 演示时的数据准备与场景脚本答辩现场最怕的是临时数据尴尬点开随访计划列表是空的或者随访记录全是测试数据看不出规则。我建议准备一份演示专用数据集5个不同病种类型、不同手术日期的患者覆盖白内障术后1周/1个月、青光眼定期随访等。每种病种至少3条已生成的随访计划且未来15天内要有几条待执行记录方便演示自动提醒和待办列表。2条随访记录指标数据要有明显对比比如一次眼压20、一次眼压25方便演示“异常预警”逻辑。演示顺序建议先功能截图兜底再现场跑通核心链路。哪怕现场出问题你是不是准备充分这件事评委一眼就能看出来功夫花在数据准备上比多写两个功能更划算。我个人在实际调试这个项目时最深的感觉是仿造一个“管理系统”不难真正拉开差距的是业务细节的完整度——把随访规则、评分算法、预警逻辑这些点做扎实这个项目就立住了。后续要扩展的话还能继续做患者微信端自助随访、脱敏数据的统计大屏接入Selenium做自动化验收测试每一个方向都是论文里现成的“展望与改进”素材也是面试时能和别人聊出来的增量亮点。