1. 项目概述与核心价值最近几年社区医疗服务的需求越来越旺盛很多朋友可能都遇到过类似的情况家门口的社区门诊看病方便但管理上还是靠手写病历、人工排号效率不高信息也容易出错。我前阵子正好参与了一个社区门诊管理系统的升级项目核心目标就是用技术手段把挂号、问诊、开药、收费这些流程都搬到线上实现数字化管理。这个项目采用了经典的SSMSpring Spring MVC MyBatis作为后端框架前端则用Vue.js来构建用户界面是一个典型的前后端分离架构。简单来说这个系统就是为社区门诊量身打造的一个“数字大脑”。它能做什么呢从患者的角度可以线上预约挂号到了门诊直接签到不用再排长队医生这边可以在电脑上直接调阅患者的电子健康档案和历史病历开处方、开检查单都一键完成系统还能自动关联药品库存和价格对于药房和收费处发药和结算也能实时联动大大减少了人工核对的工作量和出错率。对于门诊管理者系统能生成各类报表比如每日接诊量、药品消耗、收入统计等为运营决策提供数据支持。这个项目非常适合正在学习或希望深入理解企业级Web应用开发的开发者。无论你是对后端的Spring生态、MyBatis数据持久化感兴趣还是想在前端用Vue构建复杂的单页面应用SPA亦或是想搞明白前后端如何通过API优雅地“对话”这个案例都能提供一个非常完整的实战场景。接下来我就把这个项目从设计思路到具体实现再到踩过的那些“坑”给大家拆解一遍。2. 技术栈选型与架构设计思路为什么选择SSM和Vue这套组合这背后是基于社区门诊这个特定场景的深度考量。社区门诊的业务有几个特点业务逻辑相对标准但耦合紧密挂号、看诊、收费环环相扣、对系统的响应速度和稳定性有要求不能患者等着缴费系统卡住了、后期可能需要根据政策或管理需求进行灵活调整。2.1 后端技术栈SSM框架的稳与活Spring是整个后端的基石它提供的IoC控制反转和AOP面向切面编程能力让我们的代码结构非常清晰。比如我们可以把业务逻辑如挂号服务、药品管理服务定义成Service把数据访问层定义成Repository通过依赖注入的方式组装起来。这样做的好处是各个模块之间的耦合度降低了。以后如果想把病历查询的数据库从MySQL换成别的理论上只需要修改对应的Repository实现和配置而不需要动业务逻辑代码。Spring的声明式事务管理Transactional对我们这种涉及多次数据库操作如开处方同时扣减库存的业务场景至关重要它能确保数据的一致性避免出现“处方开了药却没扣掉”的尴尬情况。Spring MVC负责处理Web请求和响应。它清晰的模型-视图-控制器分层让我们能很好地组织后端的API。所有的患者、医生、药品等数据在前后端之间都以JSON格式通过RESTful API进行传输。我们为每个主要的业务实体如/api/patient,/api/registration都设计了对应的Controller。这里的一个关键设计是统一的响应封装。我们定义了一个Result类包含code状态码、msg提示信息和data实际数据字段。这样前端无论调用哪个接口收到的数据结构都是一致的大大简化了前端的错误处理和数据处理逻辑。MyBatis作为持久层框架它的优势在于灵活。社区门诊的数据模型虽然不复杂但关联查询不少。比如查询一个患者的挂号记录需要关联患者信息、医生信息和科室信息。MyBatis的XML映射文件或注解方式可以让我们非常直观地编写复杂的SQL并且能方便地进行动态SQL拼接比如根据多种条件组合查询药品。相比于全自动化的JPA HibernateMyBatis这种“半自动化”的方式让我们对SQL的执行有更强的掌控力便于进行性能优化。我们为每张表都建立了对应的实体类POJO和Mapper接口业务层通过调用Mapper接口的方法来操作数据库。注意在SSM整合时配置文件是关键。特别是spring-mybatis.xml或Java Config配置类里面要正确配置数据源DataSource、SqlSessionFactoryBean以及Mapper扫描路径。一个常见的坑是忘记在Spring MVC的配置文件中排除对Service层的扫描导致Service被加载了两次引发事务失效等问题。2.2 前端技术栈Vue.js的灵与快前端选择Vue 2.x项目启动时3.0尚未完全稳定主要是看中其渐进式、易上手和生态丰富的特点。对于门诊系统这种中后台管理类应用Vue的组件化开发模式非常适合。我们使用Vue CLI快速搭建了项目骨架并引入了几个核心生态库Vue Router管理前端路由。我们将系统划分为几个大的路由模块患者管理、医生工作站、药房管理、收费处、系统管理。每个模块对应一个路由入口再在其下配置子路由。例如医生工作站模块下可以有“今日患者列表”、“病历书写”、“处方开具”等子页面。利用路由的params或query进行页面间参数传递比如从患者列表点击某个患者跳转到病历页并携带患者ID。Vuex进行状态管理。虽然社区门诊系统不同模块间的状态共享需求不像电商那么复杂但依然有全局状态需要管理最典型的就是当前登录用户的信息是医生、药师还是收费员。我们将用户信息、权限令牌token等存储在Vuex的state中任何组件都可以方便地获取并且在用户登录、注销时进行集中更新保证了状态的一致性。Element UI作为主要的UI组件库。它提供了丰富的、样式美观的桌面端组件如表格、表单、对话框、消息提示等极大地加速了开发。我们基于门诊系统的风格对Element UI的主题色进行了定制主色调改为更符合医疗行业的蓝绿色系并封装了一些业务高频使用的组合组件比如一个包含患者基本信息卡片的对话框。前后端分离的协作模式是这个项目的关键。后端开发人员专注于API的设计、业务逻辑实现和数据库优化提供清晰的Swagger API文档。前端开发人员则基于Mock数据并行开发完全不依赖后端环境。双方通过协商好的API接口契约请求格式、响应格式、状态码含义进行对接。这种模式提升了开发效率也使得前后端可以独立部署。3. 核心功能模块设计与实现细节整个系统围绕门诊的核心业务流程设计了五大功能模块。下面我挑几个有代表性的讲讲具体是怎么设计和实现的。3.1 患者挂号与队列管理模块这是系统的“入口”。我们设计了线上预约和现场挂号两种方式。线上预约患者通过前端页面选择科室、医生和可预约的时间段后端需要逻辑排除医生已休假、号源已满的时间。提交后后端生成一条预约记录状态为“待就诊”。现场挂号收费员操作流程类似但通常立即进入当日队列。核心难点在于实时队列的管理与展示。我们并没有使用复杂的消息队列而是采用了一种基于数据库状态标记的轻量级方案。在后端我们有一张registration挂号表关键字段有patient_id,doctor_id,status状态等待中、诊中、已完成、已取消、queue_number队列号、check_in_time签到时间。当患者挂号或预约签到后系统会根据该医生当前“等待中”状态的最大队列号1为其分配queue_number。这里必须用数据库事务和行级锁如SELECT ... FOR UPDATE来保证在高并发挂号时队列号不会重复分配。前端医生工作站和候诊屏通过WebSocket或定时轮询我们根据实时性要求选择了轮询间隔5秒调用一个特定的API如GET /api/doctor/{id}/current-queue。这个接口会返回该医生名下状态为“等待中”的患者列表按queue_number排序。医生点击“叫号”时前端发送请求后端将对应挂号记录的状态从“等待中”改为“诊中”并记录开始时间。候诊屏和医生工作站的前端收到状态更新后自动刷新队列列表。// 示例Service方法片段 (简化版) Service Transactional // 关键保证整个挂号操作的原子性 public class RegistrationServiceImpl implements RegistrationService { Autowired private RegistrationMapper registrationMapper; public Registration createOnSiteRegistration(Registration reg) { // 1. 获取该医生当前最大的队列号并加锁 Integer maxQueueNum registrationMapper.selectMaxQueueNumByDoctor(reg.getDoctorId()); int nextQueueNum (maxQueueNum null) ? 1 : maxQueueNum 1; reg.setQueueNumber(nextQueueNum); reg.setStatus(等待中); reg.setCheckInTime(new Date()); // 2. 插入新的挂号记录 registrationMapper.insert(reg); return reg; } }实操心得队列号的生成是并发安全的重灾区。最初我们没用FOR UPDATE锁在模拟多人同时挂一个医生的号时出现了重复队列号。加上事务和锁之后问题解决。另外前端轮询的间隔需要权衡太短增加服务器压力太长则实时性不够。5秒对于门诊场景是较为合适的。3.2 电子病历与处方管理模块这是医生工作的核心。我们设计了一个单页面应用SPA风格的“医生工作站”。病历书写采用富文本编辑器我们集成了wangEditor支持文字、段落格式同时为了结构化存储我们还设计了关键字段如“主诉”、“现病史”、“既往史”、“诊断”等医生可以混合使用自由文本和表单填写。处方开具这是业务逻辑最复杂的地方。前端组件是一个动态表单医生输入药品名称支持拼音首字母模糊搜索后端对应数据库查询选择规格、数量后系统需要实时做几件事药品库存校验每添加一种药前端会异步请求检查该药品的当前库存是否充足。不足则立即提示。配伍禁忌提醒在后端我们维护了一个药品配伍禁忌规则表。当处方中包含多种药品时提交前会调用一个校验接口后端逻辑会遍历处方中的药品组合查询禁忌表如有冲突则返回具体的警示信息。自动计算金额根据药品单价和数量实时计算小计和处方总金额并展示给医生和患者确认。处方与病历、收费的关联是通过数据库的外键实现的。一张prescription处方表会关联medical_record病历ID和registration挂号ID。当医生保存处方时后端在一个事务内完成以下操作更新病历内容。插入处方主记录。插入处方明细prescription_item记录每种药品、数量、单价。预扣减药品库存drug_stock。注意这里是“预扣减”即生成一个“待发药”的锁定库存而不是实际减少。只有当药房实际发药后库存才会最终扣减。这避免了处方开了但患者不去取药导致的库存错误。!-- 示例MyBatis Mapper XML片段开具处方 -- insert idinsertPrescription parameterTypePrescription useGeneratedKeystrue keyPropertyid INSERT INTO prescription (record_id, registration_id, total_amount, create_time, status) VALUES (#{recordId}, #{registrationId}, #{totalAmount}, NOW(), 待缴费) /insert update idlockDrugStock UPDATE drug_stock SET locked_quantity locked_quantity #{quantity}, available_quantity total_quantity - locked_quantity WHERE drug_id #{drugId} AND available_quantity #{quantity} /update注意事项药品库存的并发控制非常重要。上面的lockDrugStock语句通过一个UPDATE条件available_quantity #{quantity}实现了“检查并锁定”的原子操作。如果库存不足该语句影响的行数为0业务层就可以据此判断并返回“库存不足”的错误。这比先SELECT查询再UPDATE的方式更安全。3.3 药房发药与库存管理模块药房人员登录系统后会看到一个“待发药”任务列表列表来源于状态为“待发药”的处方。发药流程药师点击一条任务核对处方信息和患者信息后点击“发药”。后端接口会执行校验该处方状态是否为“待发药”。将处方状态更新为“已发药”。执行最终的库存扣减UPDATE drug_stock SET total_quantity total_quantity - #{quantity}, locked_quantity locked_quantity - #{quantity} WHERE drug_id #{drugId}。记录一条发药流水。库存管理除了动态扣减还提供了库存盘点、设置高低库存预警、药品入库采购等功能。所有库存变动都有详细的流水记录stock_flow便于追溯。前端实现上我们利用Element UI的el-table展示任务列表并使用了“作用域插槽”scoped slot来自定义操作按钮列。对于库存预警我们设置了一个定时任务使用Spring的Scheduled注解每天凌晨检查库存对于低于安全库存的药品在药房管理首页进行高亮提示并可以一键生成采购申请单。4. 数据库设计与关键业务逻辑数据库设计直接影响了系统的性能和扩展性。我们遵循了第三范式以减少数据冗余但在一些高频查询的场景也做了适当的反范式优化。4.1 核心表结构设计patient患者表存储患者基本信息。id_card身份证号设为唯一索引用于快速识别患者。考虑到隐私我们对姓名、电话等敏感信息在数据库日志和传输中进行了脱敏处理。doctor医生表 department科室表多对一关系一个科室有多个医生。registration挂号表核心业务表之一。字段包括id,patient_id,doctor_id,status,queue_number,type预约/现场,fee挂号费,create_time等。建立了对patient_id,doctor_id,status的复合索引以加速根据医生和状态查询队列。medical_record病历表与registration一对一关联。包含registration_id,subjective主诉,objective查体,assessment诊断,plan治疗计划等字段。我们将富文本内容单独存在一个TEXT类型的字段中。prescription处方表 prescription_item处方明细表一对多关系。处方表关联record_id和registration_id记录总金额和状态待缴费、待发药、已发药、已取消。明细表记录每种药品的drug_id,quantity,unit_price。drug药品字典表 drug_stock药品库存表药品字典表记录药品的通用信息名称、规格、厂家、单价等。库存表通过drug_id关联记录total_quantity总数量、locked_quantity锁定数和available_quantity可用数是一个计算字段。这种设计将相对静态的药品信息和动态的库存信息分离。financial_flow财务流水表记录每一笔收退款包括registration_id,prescription_id,amount,type挂号费、药费、检查费,payment_method现金、医保、微信等,operator_id。这是对账和统计的核心。4.2 关键业务逻辑实现1. 事务边界的划分我们严格遵循“业务方法即事务边界”的原则。例如createPrescription开具处方方法上加了Transactional注解确保病历更新、处方插入、库存预扣减要么全部成功要么全部回滚。而对于单纯的查询方法如getPatientQueue则不加事务或标记为Transactional(readOnly true)以提升性能。2. 统一异常处理我们利用Spring MVC的ControllerAdvice和ExceptionHandler实现了全局异常处理。将业务异常如“库存不足”、“号源已满”、参数校验异常使用JSR-303的Valid注解和系统异常如数据库连接失败进行分类捕获并转换为前面提到的统一Result对象返回给前端。这样前端只需要判断result.code是否等于成功码如200否则弹出result.msg提示即可异常处理逻辑非常清晰。3. 数据权限控制社区门诊虽然不大但数据权限仍需控制。医生只能看到和处理自己科室或自己的患者药房人员只能看到发药相关的信息。我们在后端Service层的方法中加入了权限校验逻辑。例如在getMyTodayPatients方法里会从SecurityContext我们整合了Spring Security中获取当前登录医生的ID然后只查询该医生的挂号记录。避免在Controller层或SQL层做复杂的过滤保持逻辑集中。5. 前端工程化与性能优化实践一个管理系统的前端除了功能用户体验和性能也至关重要。5.1 组件化设计与状态管理我们严格按照业务模块划分Vue组件。例如在医生工作站模块下有PatientQueue.vue患者队列、MedicalRecordEditor.vue病历编辑器、PrescriptionWriter.vue处方开具等组件。对于像“患者信息展示卡片”这种在多个地方用到的UI我们将其抽离成可复用的PatientInfoCard.vue组件通过props接收患者数据。对于跨组件状态我们合理使用了Vuex。例如当前登录用户信息、全局的通知消息数量等存储在Vuex中。但对于像“处方编辑中的临时药品列表”这种仅限于单个页面复杂组件内部的状态我们并没有放入Vuex而是使用组件的data或Composition API的reactive/ref来管理避免Vuex状态树过于臃肿。5.2 API请求封装与拦截我们使用axios作为HTTP客户端并对其进行了全局封装。创建实例与配置基地址const service axios.create({ baseURL: process.env.VUE_APP_API_BASE_URL })。请求拦截器主要用来在每次请求的header中自动添加JWT Tokenconfig.headers[Authorization] Bearer getToken()。响应拦截器这是核心。我们在这里处理通用的响应逻辑。如果响应result.code是成功码则直接返回result.data给业务代码。如果是“Token过期”如401则自动跳转到登录页。如果是其他业务错误则使用Element UI的Message组件统一弹出错误提示并返回一个Rejected Promise阻止后续业务代码执行。// src/utils/request.js 示例片段 service.interceptors.response.use( response { const res response.data // 假设业务成功码为200 if (res.code 200) { return res.data } else { // 业务逻辑错误 Message.error(res.msg || Error) return Promise.reject(new Error(res.msg || Error)) } }, error { // HTTP状态码错误如401, 500等 if (error.response.status 401) { Message.error(登录已过期请重新登录) router.push(/login) } return Promise.reject(error) } )5.3 性能优化点路由懒加载在router.js中我们使用动态import语法来定义路由组件这样每个业务模块会被打包成独立的JS文件chunk只在用户访问该路由时才加载显著提升了首屏加载速度。{ path: /doctor, component: () import(/views/doctor/Index.vue), children: [...] }表格数据虚拟滚动对于可能展示大量数据的表格如历史病历查询我们使用了Element UI的el-table并结合vue-virtual-scroller插件实现了只渲染可视区域内的行极大提升了渲染性能。图片等静态资源优化将药品图片等静态资源上传至云存储或CDN减少服务器压力。在前端对展示型图片进行懒加载使用v-lazy指令。API请求防抖与缓存对于搜索框的输入联想功能我们使用了lodash的debounce函数进行防抖避免频繁请求。对于一些不常变化的字典数据如科室列表、药品分类在首次获取后存储在Vuex或本地存储LocalStorage中并设置合理的过期时间。6. 部署上线与运维监控项目开发完成后我们将其部署在了一台CentOS服务器上。6.1 后端部署打包使用Maven的package命令生成一个可执行的JAR文件内嵌Tomcat或WAR包。我们选择了JAR包部署更简单。上传与运行将JAR包上传至服务器。使用nohup java -jar clinic-system.jar --spring.profiles.activeprod app.log 21 命令在后台运行。这里--spring.profiles.activeprod指定使用生产环境的配置文件application-prod.properties其中配置了生产数据库地址、Redis连接等。使用Nginx反向代理为了让前端能访问后端API我们在Nginx中配置了反向代理。将/api/路径的请求转发到后端Spring Boot应用默认8080端口。location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }6.2 前端部署构建在本地或CI/CD服务器上运行npm run build生成静态文件在dist目录下。上传将dist目录下的所有文件上传到服务器的Web目录如/usr/share/nginx/html/clinic-frontend/。Nginx配置配置一个Server块将根目录指向前端文件并设置try_files来处理Vue Router的history模式路由避免刷新404。server { listen 80; server_name clinic.yourdomain.com; root /usr/share/nginx/html/clinic-frontend; index index.html; location / { try_files $uri $uri/ /index.html; } # 反向代理后端API的配置同上 location /api/ {...} }6.3 遇到的典型问题与排查前端路由刷新404这是部署Vue history模式最常见的问题。根本原因是Nginx在收到一个像/doctor/workstation这样的路径请求时会去root目录下找对应的文件或文件夹显然找不到。解决方案就是上面Nginx配置中的try_files $uri $uri/ /index.html;它会让Nginx在找不到对应资源时返回index.html由前端路由自己去处理。跨域问题CORS在开发阶段前端运行在localhost:8080后端在localhost:8081浏览器会因为同源策略阻止请求。我们通过在后端Spring Boot配置中增加一个WebMvcConfigurerBean来解决允许开发环境的源进行跨域访问。在生产环境由于前后端通过同一个域名不同路径访问不存在跨域问题此配置应关闭或严格限制来源。数据库连接池耗尽在压力测试时偶尔会出现“Cannot get JDBC Connection”的错误。检查发现是默认的HikariCP连接池配置较小。我们在application-prod.properties中调整了参数spring.datasource.hikari.maximum-pool-size20根据服务器配置和预期并发调整并设置了合理的连接超时和空闲超时时间。前端内存泄漏在长时间使用后浏览器标签页内存占用越来越高。通过Chrome DevTools的Memory面板录制堆内存快照发现是一些被废弃的Vue组件实例如弹窗、复杂表格由于被全局事件总线Event Bus或第三方库引用而未被垃圾回收。解决方法是在Vue组件的beforeDestroy生命周期钩子中手动移除事件监听器、清除定时器、解绑第三方插件实例。这个项目从设计到上线的整个过程让我对前后端分离的中小型业务系统开发有了更深的体会。技术选型没有银弹SSMVue这套组合在应对社区门诊这类传统行业信息化需求时展现了良好的稳定性、开发效率和可维护性。最大的收获不是用了多少炫技的新框架而是如何用扎实的技术稳妥地解决一个个具体的业务问题并在性能、安全、用户体验之间找到平衡点。