之前给一家社区门诊做过一套完整的出诊挂号就诊检查管理系统从前端页面到后端接口再到上线部署前后跑了将近三个月才真正稳定下来。技术组合就是标题里的这套后端用 SSMSpring SpringMVC MyBatis前端用 Vue 全家桶前后端分离开发。今天不聊什么高大上的架构就把整个项目的核心设计、关键实现和踩过的坑完整捋一遍给准备做同类系统的同学一份真正能照着落地的参考。这套系统本质上是把医院门诊线的核心业务搬到了线上医生出诊排班、患者挂号、医生接诊写病历、开检查单、回填检查结果。业务流程不算复杂但它有医疗行业的特殊性——数据要准、状态流转要清晰、操作要符合一线医生的使用习惯。下面我会从项目设计思路、后端实现、前端实战、联调部署到问题排查按一条完整的开发链路讲清楚。1. 项目整体设计从门诊业务到技术选型的完整思路1.1 门诊管理的真实业务拆解做管理系统第一步不是写代码而是把业务拆清楚。我当时花了两天蹲在门诊部看他们线下怎么干活才把流程理顺。整套系统围绕的核心链路就五步维护科室和医生、配置出诊计划、患者挂号、医生接诊、检查检验。第一步是基础数据。科室表、医生表、号源表是底层支撑没有这些后面挂号就诊全是空谈。第二步是出诊排班医生哪天出诊、放多少个号、号分上午下午这是号源表的核心逻辑。第三步是患者挂号可以现场挂也可以预约挂完号之后号源要实时扣减这里涉及并发控制。第四步是就诊医生看到候诊列表叫号、接诊、写诊断信息。第五步是检查医生给患者开检查申请患者去做检查检查科室回填结果医生在系统里查看报告。这五步串起来就是系统的核心业务流程。设计数据库表的时候我是按照订单系统的思路来建模的挂号记录就是一张主订单就诊记录、检查申请、检查结果都是围绕它展开的子单据。这样设计的好处是每次状态变更都有迹可循排查问题的时候能顺着单据链路追下去。1.2 为什么是 SSM Vue 而不是其他组合现在提到 Java Web 开发主流选择已经是 Spring Boot Spring Cloud 那一套了。但 SSM 并没有过时很多老项目、教学项目、中小型内部系统仍然在用这套组合。它把 Spring 的依赖管理、SpringMVC 的请求分发、MyBatis 的 SQL 控制力结合得很好学习曲线比 Spring Boot 稍微陡一点但一旦跑通了对理解 Web 开发底层机制非常有帮助。SSM 的定位很清晰Spring 负责业务对象的生命周期管理SpringMVC 负责接收 HTTP 请求并调用对应的 ControllerMyBatis 负责数据库访问。三层各司其职代码边界分明。配合 Vue 做前后端分离后端只输出 JSON 数据前端负责页面渲染和交互两边通过 RESTful 接口通信。选择 Vue 的原因也很实际生态成熟、中文资料多、组件化开发效率高搭配 Element UI 可以快速搭出后台管理界面。Vue Router 做页面跳转Axios 做 HTTP 通信Vuex 做全局状态管理——这三个基本就是 Vue 项目的标配三件套。前后端分离之后前端和后端团队可以并行开发只要提前约定好接口文档开发效率比传统 JSP 模式高出一大截。2. 后端核心实现SSM 框架整合与业务落地2.1 SSM 整合第一步把三个框架的依赖关系理清楚SSM 项目最劝退新手的地方不是业务代码而是环境搭建。一旦依赖冲突或者配置漏掉启动就报错一报错就是一长串堆栈。我的经验是先把 pom.xml 理清楚Spring 版本、SpringMVC 版本、MyBatis 版本必须匹配最好统一用一套 release 版本避免出现 Spring 5 混 Spring 4 这种低级错误。核心依赖大概是这么几类spring-context 负责 IOC 容器、spring-webmvc 负责 MVC 层、mybatis 负责持久层框架本身、mybatis-spring 负责让 MyBatis 跟 Spring 整合、druid 或者 c3p0 做连接池、mysql-connector-java 做数据库驱动。如果你用的是 Maven 骨架记得先把编译插件配好Java 版本统一用 1.8不然编译阶段就会卡住。配置文件的组织我建议按功能拆分不要全部堆在一个 applicationContext.xml 里面。我当时拆成三个spring-dao.xml 只配数据源、事务管理器和 SqlSessionFactoryspring-mvc.xml 配包扫描和视图解析器spring-service.xml 配业务层组件扫描。每个文件职责单一出了问题定位快。Web 层入口就是 web.xml 里配置 DispatcherServlet加载 spring-mvc.xml。这块有一个必踩的坑Spring 容器和 SpringMVC 容器重复扫描的问题。如果 spring-mvc.xml 的包扫描把 Service 注解的类也扫进去了就会出现一个业务类被创建两遍的情况事务注解有时候会莫名其妙失效。处理方法是 Controller 层只在 spring-mvc.xml 里扫描Service 层和 DAO 层由 spring-dao.xml 和 spring-service.xml 管理各扫各的包互不越界。2.2 SSM 常用注解复盘Controller、Service、Repository 是怎么配合的SSM 的日常开发几乎就是在写注解。很多新手对 .ssh 注解的理解停留在照着抄的层面我建议把每个注解背后的作用搞清楚。先看组件注册这组。Controller 标记控制器类让 SpringMVC 识别到这是一个请求处理器。Service 标记业务类交给 Spring 容器管理事务注解 Transactional 通常加在这一层的实现类上。Repository 标记 DAO 层类或者交给 MyBatis 扫描 Mapper 接口。Component 是通用注解工具类、配置类这类没有明确层次的组件用它。再看依赖注入这组。Autowired 是默认按类型注入如果同一个接口有多个实现类要配合 Qualifier(beanName) 指定具体名称或者直接用 Resource(name xxx) 按名称注入。我实际开发中用 Resource 更多一些因为它是 Java 原生注解按名称注入的语义更直观Spring 环境下不会有歧义。然后是请求映射这组。RequestMapping 是最基础的可以加在类上定义模块前缀比如 /api/registration也可以加在方法上定义具体接口。到了子路径级别Spring 4.3 之后提供了 GetMapping、PostMapping、PutMapping、DeleteMapping 这些组合注解语义更清晰。我在挂号模块用的就是 PostMapping(/appointment) 这种写法配合 RequestBody 接收前端传过来的 JSON比用 HttpServletRequest 一个个取参数干净得多。参数处理这块也是个高频错点。RequestParam 用于接收 query 参数PathVariable 用于接收 URL 路径参数RequestBody 用于接收 JSON 体。如果你用 RequestBody 接收对象前端传的 JSON 字段名必须和对象属性名一致否则反序列化之后全是 null。我当时联调接口的时候因为前端传的是 firstName后端对象属性是 name对齐花了不少时间。2.3 号源管理与挂号模块的实现细节挂号是整个系统里开发难度最高、并发要求最严的模块。号源不能超卖一个医生一天放 20 个号第 21 个患者必须提示已满。这个约束用代码实现的时候最直接的方式就是在数据库层面加条件更新。核心表设计大概是这样的doctor_schedule 表记录某个医生某一天出诊放号总量 total已约数量 booked。患者挂号时执行的 SQL 就是 update doctor_schedule set booked booked 1 where id ? and booked total。这行 SQL 利用数据库行锁的原子性保证了并发情况下不会超卖。JDBC 返回影响行数如果返回值是 0说明号已经约满直接提示用户换号源。挂号成功后系统需要同时生成一条挂号记录 registration 表数据并且把号源表的状态更新。这里有一个分布式事务的经典问题两步操作不在同一个事务里就会出现挂号记录写了但号源没扣减的脏数据。我的处理方式很朴素——在 Service 层加 Transactional把号源更新和挂号记录插入放在同一个事务方法里任何一步失败整体回滚。单库场景下事务能解决 99% 的一致性问题没必要一上来就引入分布式事务框架。挂号模块还要考虑取消挂号、号源释放的逻辑。我设计的策略是取消挂号时更新 registration 表的 status 字段为 cancelled同时把 doctor_schedule 表的 booked 减一。这里必须用乐观锁的思路在 update 语句里带上原状态条件防止用户在取消的同时又去改签其他号源导致状态错乱。2.4 就诊与检查流程的数据流转就诊流程的核心是让医生在电脑上能看到候诊列表点击接诊后跳转到诊断页面写完病历之后可以开检查单。这个流程涉及三张核心表registration 表存放挂号记录diagnosis 表存放就诊信息exam_order 表存放检查申请。候诊列表的查询就是根据当前医生的 ID查出所有 status 1已挂号待就诊的挂号记录按挂号时间和号序排序。医生点击接诊时前端跳转到诊断页面同时调用后端接口把挂号记录状态改成就诊中。等医生保存诊断信息后状态改成已完成同时生成一条 diagnosis 记录。这里每个状态变更最好都记录操作时间后续要查某个患者什么时候看的病一目了然。检查流程是独立的子链路。医生在诊断页面选择开检查单前端弹出检查项选择列表提交后生成 exam_order 记录状态是待缴费或者待执行业务上可以自行定义。检查科室的人员登录系统后看到分配过来的申请单执行检查后回填 exam_result 表。医生再次打开诊断页面时可以看到检查结果状态的变化。这套数据流设计的核心是挂号记录是主链路诊断、检查都是从链路用外键关联挂号记录 ID。任何一次流转查错只要顺着 registration_id 去 join 关联表就能定位。千万别把数据拍平放在一张大表里医疗数据是要长期留存的拆分清晰了扩展性才会好。3. 前端 Vue 实战路由、组件与接口联调的落地细节3.1 Vue 项目目录结构与路由设计Vue 项目的目录结构如果一开始不规划好页面多了之后会非常痛苦。我这边是用的标准 Vue CLI 工程现在新项目可以用 Vite但很多 SSM 项目的老代码还是 Vue CLI 为主基础目录大概是views 目录放页面级组件components 目录放可复用组件router 目录放路由配置store 目录放 Vuex 状态api 目录放接口请求模块utils 目录放工具函数。路由设计上我建议完全跟着业务模块走。做一个后台管理系统登录后主页布局是统一的侧边栏加顶栏内部是嵌套路由。一级路由是布局组件二级路由是具体业务页面比如 /dashboard 是工作台/doctor/schedule 是排班管理/doctor/consult 是接诊页面/patient/registration 是挂号页面/exam/order 是检查管理。这里用了 Vue Router 的 children 配置代码可读性和页面结构保持一致。路由还有一个容易忽略的点懒加载。后台管理系统页面一多如果全部同步引入首屏加载会非常慢。用 route 的 component 写成箭头函数配合 import()页面就会按需加载访问到哪个模块才加载对应的 JS chunk。我在排班页面、诊断页面、检查管理页面上都做了拆包首屏体积减少了差不多三分之一。路由守卫是必须做的。用户没登录路由跳转应该被拦下来重定向到登录页。我在全局前置守卫里读取 localStorage 里的 token有 token 放行没有就强制回登录页。这个逻辑看起来简单但如果配合路由元信息做权限控制比如有的页面只有管理员能进就需要在 meta 里加 role 字段在守卫里做角色校验。3.2 核心页面组件拆解挂号页、诊断页、检查页的交互逻辑页面设计要贴近真实使用场景。挂号页面主要服务的是门诊收费挂号窗口核心交互逻辑是选择科室、选择医生、选择日期和号源时段然后录入患者信息提交挂号。这里有几个组件设计上的细节。科室和医生的数据是级联的我做了两级联动下拉框选择科室后触发医生列表接口医生列表接口返回当前科室所有医生。选完医生后再触发号源查询接口返回某天某医生剩余的号段。Vue 的 watch 或者组件事件在这里比手动改 DOM 方便得多data 一变视图自动刷新。诊断页面是医生用的界面要求信息密度高左边是候诊列表右边是患者基本信息加诊断录入区。这个页面我拆成了三个组件WaitingList.vue 负责显示候诊患者列表PatientInfo.vue 显示患者的基本信息和历史就诊记录DiagnosisForm.vue 负责诊断内容和检查申请单的提交。组件之间通过 ref 或者自定义事件传递数据页面数据层用 Vuex 维护当前的医生 ID 和选中的患者 ID。检查页面相对简单负责两块给医生开检查单的弹窗以及给检查科室用的执行列表。弹窗组件我在项目里封装成了一个全局组件通过 visible 属性控制显示隐藏提交时用 Promise 回调通知父组件刷新列表。这样弹窗内部逻辑和外部业务是解耦的后面在别的地方复用就不用重写一遍。3.3 Axios 请求封装和 Token 鉴权实战后端接口需要做登录鉴权前端的 Axios 就要统一处理 token 的携带和 401 的跳转。我的做法是创建一个独立的 http.js 工具文件通过 axios.create 创建实例设置 baseURL 和请求超时时间。请求拦截器里做的事情很简单从 localStorage 读取 token如果有就在 config.headers 里加 Authorization 字段。响应拦截器里做的事稍微多一点返回 code 为 200 的数据正常放行后端返回 401 的时候说明 token 过期清除本地登录信息跳回登录页后端返回业务错误码比如 50001号源已满就用 ElMessage 弹出提示并且把错误信息 catch 给到调用方。Axios 封装的好坏直接影响整个项目的开发体验。我见过不少项目里每个页面都在重复写 axios.get .then .catch 的样板代码接口一多就乱套。最好是统一走 http.get(/api/xxx, { params }) 这样一层薄封装返回 Promise页面里用 async/await 接收数据。错误处理统一在拦截器做页面上不需要关心 HTTP 状态码只需要处理自己关心的业务码。4. 前后端联调与部署跨域、打包、上线的完整闭环4.1 开发环境跨域怎么解决前后端分离之后跨域问题一定会遇到。前端的开发服务器跑在 localhost:8081后端接口跑在 localhost:8080前端去请求后端接口浏览器会拦截这个跨域请求。跨域解决的方案有两种一种是后端加 CORS 过滤器一种是前端用反向代理。开发阶段我强烈建议前端做代理在 vue.config.js 里配置 devServer 的 proxy 字段把 /api 开头的请求转发到后端的 8080 端口。这样前端的页面请求被代理转发浏览器看到的请求源始终是同源不会触发跨域报错。后端同时也要预留 CORS 支持因为正式环境下可能把前端打包的文件和接口分开部署这时候同样有跨域问题。在 SpringMVC 中加一个 CorsFilter或者直接在 Controller 类上加 CrossOrigin 注解就可以实现后端允许跨域。需要注意允许跨域的配置里不要写死 origin 为 * 再允许携带凭证否则浏览器会直接拒绝带 Cookie 的请求Token 方式的跨域一般要指定允许的 origin 域名。4.2 Vue 打包放进 SSM 项目的两种方式部署方式我做过分两种各有优劣。第一种是前端打包后直接放进 SSM 项目的 webapp 目录下跟后端打成同一个 WAR 包。Vue 项目里执行 npm run build生成的 dist 目录就是静态文件把里面的内容复制到 webapp 的根目录下然后后端把静态资源映射到首页即可。这种方式的优点是部署简单一个 Tomcat 就搞定不需要额外配置 Nginx缺点是前后端代码耦合在一个包里前端改个页面整个后端也要重新发布。第二种是前后端彻底分离前端 dist 文件部署到 Nginx后端 SSM 项目部署到 TomcatNginx 配置一个反向代理把 /api 开头的请求转发到 Tomcat。这种方式的优点是前后端各自独立发布互不影响上线后我只需要改一个前端文件就直接生效不需要动后端。缺点是部署链路多了一层运维成本稍微增加。我个人更推荐第二种尤其项目往下迭代的时候前端页面改动的频率远高于后端接口分离部署能减少很多无谓的发布操作。如果项目量级不大第一种也够用根据自己的运维能力来选。4.3 核心表结构参考设计数据库设计是整个系统的地基我贴一下我实际在用的核心表结构和字段设计思路供你参考。医生表 doctorid、name、department_id、job_title、introduction、status。科室表 departmentid、name、description、status。排班表 doctor_scheduleid、doctor_id、work_date、period(上午/下午)、total_number、booked_number、status。挂号表 registrationid、patient_name、patient_phone、doctor_id、schedule_id、reg_date、period、status、create_time。诊断表 diagnosisid、registration_id、doctor_id、symptom_desc、diagnosis_result、advice、create_time。检查表 exam_orderid、registration_id、doctor_id、exam_items、status、create_time检查结果表 exam_resultid、exam_order_id、result_content、doctor_id、create_time。这套表结构不是完全规范化到极致而是结合了查询效率做的合理冗余。比如 registration 表存了 patient_name 和 patient_phone虽然可以通过患者表关联查询但挂号列表页经常要显示这些信息冗余存储可以减少联表次数。医疗系统里这种用空间换查询效率的做法很常见。字段命名建议统一用下划线风格MySQL 在 Linux 下表名区分大小写容易踩坑全部用小写命名最稳妥。时间字段统一用 datetime状态字段用 tinyint 加注释比如 status 0 表示待就诊1 表示就诊中2 表示已完成3 表示已取消。命名规范统一了后期维护的人包括未来的自己都会感谢你。5. 常见问题与排查实录上线前一定要避开的坑5.1 我在实操中遇到的典型问题和处理方案第一个问题Tomcat 启动后报 ClassNotFoundException。排查思路是先看是不是包没打进去Maven 项目在 install 的时候没有把依赖 jar 包复制到 WEB-INF/lib 下。解决方案是在 pom 里配置 maven-war-plugin确保依赖被正确打包。还有一个相关问题是依赖冲突典型的比如 Netty 和 Tomcat 的 servlet-api 冲突解决办法是用 exclusions 排除掉重复传递的依赖。第二个问题前端请求接口报 404。排查思路大概率是路径不对。Vue 开发模式下如果 baseURL 配的是 /api而代理转发规则没有匹配上请求就会打到前端 devServer 上返回 index.html导致 404。解决办法是把后端接口路径统一带上 /api 前缀然后自己在前端代理配置里明确转发规则。第三个问题前后端联调时参数传过去后端获取为 null。这个高频问题多半出在 JSON 字段名不一致或者后端接收参数的对象没有写 getter/setter。我用 Lombok 之后这种情况少了很多但前后端约定字段名仍然是最关键的最好维护一份接口文档字段名大小写、嵌套结构都写清楚。第四个问题日历控件选了日期但是传给后端后格式不对。Vue 生态里常用的日期组件默认输出的是 Date 对象序列化成 JSON 之后变成时间戳后端接收 LocalDate 的时候就会报格式错误。处理方式是在后端统一配置 Jackson 的日期序列化格式或者前端选完日期后先格式化字符串再提交。我在项目里是两种都做了双保险。5.2 几个值得单独说明的避坑心得先说明一个高频翻车点事务注解失效。Transactional 默认只回滚 RuntimeException如果你手动抛出一个 checked exception它是不会回滚的。我在写挂号和号源扣减逻辑的时候传了一个业务异常类继承 RuntimeException 才保证事务里任何异常都能回滚。另外同类内部方法调用导致事务失效也是老问题某个 Service 的公有方法直接调了另一个被 Transactional 修饰的方法但没经过代理对象注解就不会生效。这个最稳妥的规避方式是不把有事务的方法放到同类内部调或者通过注入自身代理对象来调用。再说明一个 MyBatis 的坑动态 SQL 里的 if 判断字符串类型千万别写成if teststatus ! null and status ! 如果 status 是 Integer空字符串比较就会报错。这种问题是运行期的不跑数据根本发现不了。我的建议是 MyBatis 的 XML 文件写完一定要用那种比较全面的测试数据把每个 if 分支都跑到别只盯着正常数据。还有就是前端的坑大量组件状态踩坑。Vue 的 data 必须是对象但这带来的坑是数组和对象的引用传递同一个数组被两个组件引用一个改了另一个跟着变排查半天才发现是引用问题。解决方案是在组件里用 computed 或者深拷贝的方式来处理跨组件数据传递千万别直接把 state 塞给 props 后子组件里再乱改。5.3 性能优化与体验打磨医院门诊场景并发量没有电商那么夸张但高峰期挂号请求依然会有较大瞬时压力。常用做法是给查询接口做缓存比如科室列表、医生排班这种读取频率极高、修改频率低的接口用 Redis 做缓存可以明显降低数据库压力。当然SSM 项目里也可以用 Spring Cache 注解实现Cacheable 配置在 Service 方法上每次进入方法前先查缓存命中就直接返回。挂号接口我做了防重提交处理。前端点按钮后设置 loading 状态禁止二次点击后端接口再判断同一手机号同一号源短时间内不能重复挂号。这种双保险是必要的因为客户端的控制永远不能替代服务端的校验服务端不处理用户快速双击就能捅穿防线。移动端的适配问题也要提前考虑。我给门诊窗口用的系统是 PC 端的分辨率但在 iPad 上也要正常用。Element UI 的栅格布局本质上就是为多屏适配设计的填报界面尽量用栅格布局而不是固定宽度这在后面要适配多设备时能少改很多代码。5.4 上线前后的检查清单上线是项目最紧张的时刻我把实际踩过坑的检查项整理成一份清单数据库连接池的初始连接数有没有调大不支持并发和超时有人设置太小高峰一上来就连接超时MyBatis 的 SQL 有没有全部测试过 where 条件在空值情况下的表现避免上线后某些条件丢数据日志级别是否调整到 INFO不要刷 ERROR 刷得飞起前端打包前是否已经配好生产环境接口地址Vue 项目不同环境用不同环境变量文件这是个高频问题Tomcat 连接超时和线程池参数有没有调过默认值通常扛不住正式流量。这些检查项每一条看起来都不难但每条都真实地在我的项目里出过问题。上线前把清单过一遍比上线后兴奋地看着监控面板真实得多。6. 写在最后SSM 医院项目的经验复盘这个项目做下来我最深的体会是管理系统表面上是代码问题实质上还是业务理解问题。技术选型、框架整合、组件拆解这些只要花时间总能学会但把挂号、就诊、检查这套流程真正跑顺畅需要你花时间去理解一线用户的真实操作习惯。医生不会关心你用的是 MyBatis 还是 JPA他们只关心接诊页面的按钮是不是一目了然、病历录入是不是够快、检查申请是不是顺手。另外就是事务和并发的问题在业务少的时候看起来不是问题业务量一旦上来就会集中爆发。号源扣减、状态流转、防重提交这些设计必须在开发初期就定好方案等你上线之后再去打补丁付出的代价会是翻倍的。如果你正在做一个相似的管理系统我给的建议是别急着写代码先把业务流程和表结构设计画出来拿给业务方确认。表结构如果设计不合理后面每一步重构都是痛苦的根源。SSM 已经是极其成熟的组合了网上资料多到看不完难点从来都在业务设计的取舍上。这个项目做完之后我还想加的功能是患者在线预约和诊间支付把链路的最后一段补上。技术上还是沿用现有的前后端分离体系后端加接口前端加页面扩展起来并不会推翻现有架构。这也是当时选这套技术栈的底气——它能稳稳撑住业务向前走。