简介在软件开发领域企业级应用开发常面临业务逻辑复杂、数据一致性要求高、多角色权限控制等挑战。其核心原理在于通过分层架构、模块化设计及成熟的技术栈组合构建稳定、可维护的后台管理系统。这类技术的价值在于能够高效地将线下业务流程数字化提升运营效率与数据治理能力。典型的应用场景包括医疗、教育、政务等行业的后台管理系统。本文以社区医疗综合服务平台为例深入探讨了如何运用SpringBoot与MyBatis-Plus等技术实现居民电子健康档案管理、药品库存管理及统一权限控制等核心功能为类似B端系统的开发提供了可复用的解决方案框架与实践参考。1. 项目概述与核心价值最近在整理过往项目时翻到了一个挺有代表性的老项目——中山社区医疗综合服务平台。这名字听起来挺“官方”对吧但它本质上就是一个典型的、面向社区医疗机构的B端后台管理系统。当时接这个活儿甲方某区域社区卫生服务中心联合体的核心诉求非常明确他们受够了纸质档案满天飞、电话预约排长队、各站点数据互不相通的混乱局面急需一个能打通“人、财、物、事”的数字化中枢。所以这个平台的设计目标远不止是一个简单的信息记录工具而是要成为支撑社区“预防、保健、医疗、康复、健康教育、计划生育”六位一体服务的运营引擎。我选择用Java SpringBoot这套经典组合拳来落地原因很实在。社区医疗机构的IT预算通常有限运维人员的技术栈也偏传统。SpringBoot的“约定大于配置”和快速启动特性能极大降低部署和后期维护的复杂度。同时Java生态的成熟与稳定意味着在居民健康档案管理、药品库存这类涉及敏感数据和复杂业务逻辑的场景下我们有海量的、经过验证的轮子各种开源组件可用不必重复造轮子能把主要精力聚焦在业务模型的抽象和流程优化上。这个项目最终交付的不仅仅是一套可运行的源码更是一套针对社区医疗场景深度定化的、可复用的解决方案框架。下面我就把这个项目的设计思路、关键实现以及踩过的那些坑掰开揉碎了和大家聊聊。2. 整体架构设计与技术选型考量2.1 业务架构与模块划分社区医疗的业务看似琐碎但梳理后核心模块非常清晰。我们将其划分为四大中心患者服务中心这是面向居民的窗口核心是居民电子健康档案EHR的全生命周期管理以及预约挂号、在线咨询、报告查询等功能。难点在于EHR的数据结构设计要能灵活兼容个人基本信息、历次就诊记录、慢病随访数据、体检报告、过敏史等异构信息。诊疗业务中心支撑医生日常工作的核心包括门诊病历书写考虑结构化录入以提高数据质量、处方开具与药品库存、合理用药规则库联动、检验检查申请与报告归集。这里的关键是业务流程的闭环管理和不同角色医生、护士、药师的协同。运营管理中心这是平台的“后台后台”涵盖药品与医疗器械的进销存管理、医护人员排班、绩效核算、财务收支统计等。库存管理需要实现批次号、效期跟踪预警临期药品这是社区药房管理的刚需。数据统计中心不单是简单的报表查询而是基于业务数据为管理者提供决策支持如常见病发病趋势分析、药品使用分析、居民健康覆盖率统计等。初期可能用静态报表但架构上要为后续的数据分析预留接口。2.2 技术栈选型详解为什么是SpringBoot 2.x而不是其他在当时现在也依然适用的背景下这是一个平衡了效率、生态和可控性的最佳选择。核心框架SpringBoot 2.3.5。这个版本稳定生态丰富。我们用它来快速集成以下几乎所有组件通过spring-boot-starter-*依赖极大简化了配置。持久层MyBatis-Plus。放弃原生MyBatis和JPA选择MyBatis-Plus主要是看中了其强大的CRUD封装和条件构造器。社区医疗业务中复杂动态查询如组合条件筛选居民档案、多维度统计报表非常多MyBatis-Plus的QueryWrapper写起来非常高效。它的代码生成器也能一键生成实体、Mapper、Service基础代码对于有大量标准增删改查的业务表如药品目录、科室信息来说开发效率提升显著。安全与权限Spring Security JWT。社区医疗系统必须区分管理员、医生、护士、药师、居民等多种角色且数据权限要精细到医生只能看自己科室或自己负责的患者。Spring Security提供了强大的认证授权框架结合JWT实现无状态令牌适合前后端分离架构。我们自定义了UserDetailsService和权限注解实现了基于URL和数据的动态权限控制。缓存Redis。主要用于两类场景一是缓存高频访问但不常变的数据如系统配置项、药品分类字典二是用作门诊高并发场景下的“减震器”比如预约号源库存的扣减通过Redis的原子操作如DECR可以有效防止超卖。消息队列RabbitMQ。用于解耦耗时操作和提升用户体验。例如居民成功预约后需要异步发送短信提醒医生开具检查单后需要异步通知检验科室。这些都用消息队列来实现避免主线程阻塞。数据库MySQL 5.7。关系型数据库是业务数据的主存储满足事务一致性要求。我们针对核心表如health_record健康档案、medical_order医嘱做了重点索引优化。注意技术选型切忌“炫技”。在资源有限的社区医疗场景稳定、可维护、社区活跃度高的技术栈远比“最新最潮”更重要。例如我们当时没有引入复杂的微服务而是采用单体架构多模块的方式因为项目初期用户量和并发并不高微服务带来的运维复杂度反而会成为负担。3. 核心功能模块实现解析3.1 居民电子健康档案EHR模块设计这是系统的基石。EHR不是一张简单的表而是一个以个人为核心的数据聚合体。1. 数据库设计我们采用“主表扩展表”的灵活设计。resident表存储居民核心身份信息ID、姓名、身份证号、联系方式、常住地址等。health_record表作为档案主表与resident一对一关联记录档案ID、建档时间、责任医生等。多个业务子表通过health_record_id与档案主表关联。例如clinic_visit门诊就诊记录。chronic_disease_followup慢病随访记录。vaccination_record预防接种记录。physical_exam_report体检报告这里可以存储报告PDF的OSS路径或结构化数据。这种设计的好处是结构清晰易于扩展。当需要新增一类健康记录如中医体质辨识时只需新增一张表不影响原有结构。2. 关键接口实现档案的“增删改查”中“查”是最复杂的。我们提供了一个强大的复合查询接口。RestController RequestMapping(/api/ehr) public class EhrController { Autowired private EhrService ehrService; GetMapping(/list) public PageResultResidentEhrVO listResidentEhr(ResidentQueryDTO queryDTO) { // 使用MyBatis-Plus的QueryWrapper构建动态查询条件 QueryWrapperResident wrapper new QueryWrapper(); if (StringUtils.isNotBlank(queryDTO.getName())) { wrapper.like(name, queryDTO.getName()); } if (StringUtils.isNotBlank(queryDTO.getIdNumber())) { wrapper.eq(id_number, queryDTO.getIdNumber()); } if (queryDTO.getChronicDiseaseType() ! null) { // 关联查询慢病表存在对应慢病记录的居民 wrapper.exists(SELECT 1 FROM chronic_disease_followup c WHERE c.resident_id resident.id AND c.disease_type {0}, queryDTO.getChronicDiseaseType()); } // ... 其他条件 wrapper.orderByDesc(create_time); IPageResident page residentMapper.selectPage(new Page(queryDTO.getPageNum(), queryDTO.getPageSize()), wrapper); // 将PageResident 转换为 PageResultResidentEhrVO并聚合关联的健康档案摘要信息 return ehrService.convertToEhrVOPage(page); } }3. 实操心得数据脱敏在查询和展示居民列表时身份证号、手机号等敏感信息必须进行部分掩码处理如110101****1234这在Service层返回VO对象时就要做好。档案合并现实中会遇到一人多档的情况。我们设计了一个“档案合并”后台任务基于身份证号、姓名等规则识别疑似重复档案经管理员确认后将次要档案的历史数据迁移到主档案下并逻辑删除次要档案。这个过程必须记录详细日志保证数据可追溯。3.2 药品库存管理模块实现社区药房的库存管理核心在于“精准”和“预警”。1. 核心表结构drug药品基础信息表药品编码、通用名、商品名、规格、厂家、单价等。drug_inventory库存表与drug关联。关键字段包括batch_number批号、expiry_date有效期至、stock_quantity当前库存、locked_quantity锁定库存如已开处方但未发放。inbound_order/outbound_order入库单/出库单记录每一次库存变动的明细、经手人、时间。2. 库存扣减逻辑——防止超发这是核心并发控制点。医生开处方时系统会预先检查并锁定库存。发药时再进行实际扣减。Service Transactional(rollbackFor Exception.class) public class InventoryServiceImpl implements InventoryService { Override public boolean lockInventory(Long drugId, String batchNumber, Integer quantity) { // 1. 使用乐观锁或悲观锁查询并锁定库存 DrugInventory inventory drugInventoryMapper.selectForUpdate(drugId, batchNumber); // 悲观锁写法 if (inventory null || inventory.getAvailableQuantity() quantity) { throw new BusinessException(药品库存不足); } // 2. 更新锁定数量 inventory.setLockedQuantity(inventory.getLockedQuantity() quantity); return drugInventoryMapper.updateById(inventory) 0; } Override public boolean reduceInventory(Long outboundOrderId) { // 根据出库单明细减少实际库存并清除对应的锁定库存 ListOutboundDetail details detailMapper.selectByOrderId(outboundOrderId); for (OutboundDetail detail : details) { DrugInventory inventory drugInventoryMapper.selectById(detail.getInventoryId()); inventory.setStockQuantity(inventory.getStockQuantity() - detail.getQuantity()); inventory.setLockedQuantity(inventory.getLockedQuantity() - detail.getQuantity()); drugInventoryMapper.updateById(inventory); // 记录库存变更流水 inventoryFlowMapper.insert(new InventoryFlow(...)); } return true; } }3. 效期预警实现我们通过一个定时任务使用SpringScheduled每天凌晨扫描drug_inventory表。Component public class DrugExpiryWarningTask { Autowired private DrugInventoryMapper inventoryMapper; Autowired private NotificationService notificationService; Scheduled(cron 0 0 2 * * ?) // 每天凌晨2点执行 public void checkExpiry() { // 查询距离过期还有30天、7天的药品 LocalDate warningDate30 LocalDate.now().plusDays(30); LocalDate warningDate7 LocalDate.now().plusDays(7); ListDrugInventory expiringSoonList inventoryMapper.selectExpiringSoon(warningDate30); for (DrugInventory item : expiringSoonList) { // 构建预警消息推送给药房管理员站内信、短信等 String message String.format(药品【%s】批号%s将于%s过期当前库存%s。, item.getDrugName(), item.getBatchNumber(), item.getExpiryDate(), item.getStockQuantity()); notificationService.sendToPharmacist(message, item); } } }踩坑记录初期我们只在出库时按效期优先先过期先出的原则排序但没有主动预警。结果导致一次盘点时发现了一批临近过期的慢性病用药处理起来非常被动。所以主动预警机制必须作为库存管理的标配。3.3 统一权限控制设计与实现多角色、细粒度权限是管理系统的灵魂。我们采用经典的RBAC角色-权限模型并进行了数据权限扩展。1. 数据库表设计sys_user用户表。sys_role角色表如超级管理员、社区站长、全科医生、护士、药师。sys_menu菜单/权限表对应前端路由和API接口。sys_user_role用户-角色关联表。sys_role_menu角色-菜单关联表。sys_data_scope数据权限规则表扩展用于控制用户能看到哪些数据如医生只能看本社区的患者。2. 核心配置类在Spring Security配置中我们自定义了访问决策逻辑。Configuration EnableGlobalMethodSecurity(prePostEnabled true) // 启用方法级注解 public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers(/api/auth/login).permitAll() .antMatchers(/api/**).authenticated() // 所有/api请求需要认证 .anyRequest().permitAll() .and() .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); } Bean public JwtAuthenticationFilter jwtAuthenticationFilter() { return new JwtAuthenticationFilter(); } }3. 数据权限拦截这是难点。我们在MyBatis层面通过插件Interceptor实现。为需要数据权限的Mapper方法自动添加SQL条件。Intercepts({Signature(type Executor.class, method prepare, args {Connection.class, Integer.class})}) Component public class DataScopeInterceptor implements Interceptor { Override public Object intercept(Invocation invocation) throws Throwable { StatementHandler handler (StatementHandler) invocation.getTarget(); MetaObject metaObject SystemMetaObject.forObject(handler); MappedStatement mappedStatement (MappedStatement) metaObject.getValue(delegate.mappedStatement); // 1. 判断该方法是否需要数据权限过滤通过自定义注解DataScope DataScope dataScope getDataScopeAnnotation(mappedStatement); if (dataScope ! null) { // 2. 获取当前登录用户的信息 UserDetails userDetails SecurityContextHolder.getContext().getAuthentication().getPrincipal(); // 3. 根据用户角色拼接额外的SQL条件例如AND community_id #{user.communityId} String originalSql (String) metaObject.getValue(delegate.boundSql.sql); String newSql addDataScopeCondition(originalSql, userDetails, dataScope); metaObject.setValue(delegate.boundSql.sql, newSql); } return invocation.proceed(); } }4. 实操心得权限缓存用户的菜单权限和API权限在登录时加载并存入Redis设置合理的过期时间。每次鉴权时从缓存读取避免频繁查询数据库。按钮级控制前端按钮的显示/隐藏可以通过后端返回的权限标识列表来控制。我们定义了一个/api/auth/permissions接口返回当前用户的所有权限码。日志记录所有敏感操作如删除居民档案、修改药品库存、查看敏感健康信息都必须记录详细的操作日志谁、何时、做了什么、IP地址这是安全审计的底线。4. 前后端分离与API设计规范我们采用前后端分离架构前端使用Vue.js后端提供纯RESTful API。4.1 统一的响应体封装为了保证前端处理的一致性所有API响应都包装在一个标准格式中。Data public class RT implements Serializable { private Integer code; // 状态码200成功其他为错误 private String msg; // 提示信息 private T data; // 响应数据 public static T RT ok(T data) { RT r new R(); r.setCode(200); r.setMsg(操作成功); r.setData(data); return r; } public static T RT error(String msg) { RT r new R(); r.setCode(500); r.setMsg(msg); return r; } // 更多预定义状态码... }通过一个全局的RestControllerAdvice对控制器异常进行统一处理将各类异常业务异常、参数校验异常、系统异常转换为统一的R对象返回。4.2 API文档与接口测试我们集成Swagger2现为Swagger3 / OpenAPI 3来自动生成API文档。在SpringBoot中配置非常简单Configuration EnableSwagger2 public class SwaggerConfig { Bean public Docket createRestApi() { return new Docket(DocumentationType.SWAGGER_2) .apiInfo(apiInfo()) .select() .apis(RequestHandlerSelectors.basePackage(com.zhongshan.platform.controller)) .paths(PathSelectors.any()) .build() .securitySchemes(securitySchemes()) // 配置JWT认证 .securityContexts(securityContexts()); } private ApiInfo apiInfo() { return new ApiInfoBuilder() .title(中山社区医疗综合服务平台API文档) .description(社区医疗管理系统后端接口说明) .version(1.0) .build(); } }这样启动项目后访问http://localhost:8080/swagger-ui.html就能看到所有接口的详细说明支持在线测试极大方便了前后端联调。4.3 前端与后端的协作要点接口联调利用Swagger文档前端开发者可以独立进行接口测试减少对后端的依赖。后端应保证接口的稳定性和文档的准确性。跨域问题在开发环境我们通过CrossOrigin注解或全局配置解决。在生产环境则通过Nginx反向代理来规避。文件上传对于体检报告、证件照等文件上传我们使用阿里云OSS等对象存储服务。后端接口只接收文件并上传至OSS然后将文件的访问URL返回给前端存储。这样做避免了服务器磁盘空间和带宽的压力。5. 部署、监控与性能优化实践5.1 多环境部署配置SpringBoot的application-{profile}.properties机制完美支持多环境。我们通常有application-dev.properties开发环境连接本地数据库。application-test.properties测试环境连接测试服务器。application-prod.properties生产环境配置正式数据库、Redis等地址。通过启动命令java -jar app.jar --spring.profiles.activeprod来激活对应环境配置。5.2 数据库性能优化随着数据量增长查询变慢是必然的。我们采取了以下措施索引优化使用EXPLAIN分析慢查询SQL为WHERE、ORDER BY、GROUP BY子句中的字段建立合适索引。例如在clinic_visit表的resident_id和visit_date上建立复合索引加速按居民和日期范围的查询。SQL语句优化避免SELECT *只取需要的字段谨慎使用JOIN尤其是多表关联和大表关联大量数据分页查询使用“延迟关联”优化。归档历史数据将超过3年的门诊详细记录迁移到历史归档表主表只保留近期数据显著提升核心业务查询速度。5.3 应用监控与日志健康检查Spring Boot Actuator 提供了/actuator/health端点可以集成到运维监控平台实时了解应用状态数据库连接、磁盘空间等。日志聚合使用Logback或Log4j2配置日志按天滚动存储。关键业务操作如处方开立、库存修改和异常错误必须打印详细日志。生产环境推荐将日志收集到ELKElasticsearch, Logstash, Kibana或Graylog等平台便于集中查询和分析。JVM监控在启动脚本中配置JVM参数如堆内存大小、GC日志输出。使用VisualVM、JConsole或Arthas等工具在需要时进行诊断。5.4 应对高并发场景的思考虽然社区医疗系统并发峰值不会像互联网应用那么夸张但在集中预约如流感疫苗接种预约时仍可能面临压力。缓存策略升级对于号源库存这种极端热点数据除了用Redis还可以考虑使用Redis分布式锁或Lua脚本保证原子性防止超卖。数据库连接池优化合理配置HikariCP等连接池参数最大连接数、最小空闲连接、连接超时时间避免连接耗尽或浪费。异步化处理将所有非实时核心的操作异步化。例如预约成功后的短信通知、数据统计报表的生成都通过消息队列发送到后台任务异步执行快速释放请求线程提升接口响应速度。6. 项目复盘与避坑指南回顾整个项目有几个关键点值得后来者特别注意需求理解的深度决定代码的复杂度初期和业务方医生、护士、管理员的沟通至关重要。不要想当然。比如“排班”功能不仅要考虑医生还要考虑护士、诊室、设备并且要处理调班、替班、节假日等复杂规则。我们第一版做得太简单后来返工代价很大。字典数据的管理像“疾病编码”、“药品分类”、“收费项目”这类字典数据一定要设计成可后台配置的不要硬编码在代码或枚举里。我们单独做了一个“数据字典”管理模块方便后续维护和扩展。事务边界要清晰一个业务操作可能涉及多张表的更新如开处方扣库存、生成订单、写病历。务必使用Spring的Transactional声明事务并仔细考虑事务的传播行为和回滚条件。对于分布式环境如后期拆服务需要考虑分布式事务方案如Seata但在单体架构下数据库事务足够了。代码的可读性与可维护性坚持良好的编码规范。我们要求Service层方法名必须清晰表达业务意图复杂的业务逻辑要抽取私有方法或独立工具类。大量使用DTOData Transfer Object进行前后端数据交互避免直接暴露数据库实体。这为后续可能的系统升级或重构减少了大量麻烦。安全无小事SQL注入坚持使用MyBatis的#{}预编译严禁字符串拼接SQL。XSS攻击对用户输入的内容如病历主诉进行转义或过滤或者在前端渲染时使用安全的文本绑定方式如Vue的{{ }}默认已转义。越权访问除了菜单权限数据权限校验必须贯穿始终。每次查询、修改、删除前都要在服务层显式校验当前用户是否有权操作目标数据。密码安全用户密码必须加盐哈希存储使用BCryptPasswordEncoder绝对禁止明文存储。这个项目从设计到上线历时近半年是一个典型的“业务驱动”型后端管理系统开发案例。它没有用到太多炫酷的新技术但把SpringBoot生态下的经典组件用扎实、用透彻稳稳地支撑起了社区医疗的日常运转。对于想深入理解如何将一个复杂的线下业务流程通过代码转化为一个稳定、易用的线上系统的朋友来说这类项目的实战价值非常高。源码本身是骨架而背后的业务思考、架构权衡和细节处理才是真正的血肉。本文还有配套的精品资源点击获取 SpringBoot+MyBatis-Plus构建社区医疗平台：架构设计与核心模块实现
简介在软件开发领域企业级应用开发常面临业务逻辑复杂、数据一致性要求高、多角色权限控制等挑战。其核心原理在于通过分层架构、模块化设计及成熟的技术栈组合构建稳定、可维护的后台管理系统。这类技术的价值在于能够高效地将线下业务流程数字化提升运营效率与数据治理能力。典型的应用场景包括医疗、教育、政务等行业的后台管理系统。本文以社区医疗综合服务平台为例深入探讨了如何运用SpringBoot与MyBatis-Plus等技术实现居民电子健康档案管理、药品库存管理及统一权限控制等核心功能为类似B端系统的开发提供了可复用的解决方案框架与实践参考。1. 项目概述与核心价值最近在整理过往项目时翻到了一个挺有代表性的老项目——中山社区医疗综合服务平台。这名字听起来挺“官方”对吧但它本质上就是一个典型的、面向社区医疗机构的B端后台管理系统。当时接这个活儿甲方某区域社区卫生服务中心联合体的核心诉求非常明确他们受够了纸质档案满天飞、电话预约排长队、各站点数据互不相通的混乱局面急需一个能打通“人、财、物、事”的数字化中枢。所以这个平台的设计目标远不止是一个简单的信息记录工具而是要成为支撑社区“预防、保健、医疗、康复、健康教育、计划生育”六位一体服务的运营引擎。我选择用Java SpringBoot这套经典组合拳来落地原因很实在。社区医疗机构的IT预算通常有限运维人员的技术栈也偏传统。SpringBoot的“约定大于配置”和快速启动特性能极大降低部署和后期维护的复杂度。同时Java生态的成熟与稳定意味着在居民健康档案管理、药品库存这类涉及敏感数据和复杂业务逻辑的场景下我们有海量的、经过验证的轮子各种开源组件可用不必重复造轮子能把主要精力聚焦在业务模型的抽象和流程优化上。这个项目最终交付的不仅仅是一套可运行的源码更是一套针对社区医疗场景深度定化的、可复用的解决方案框架。下面我就把这个项目的设计思路、关键实现以及踩过的那些坑掰开揉碎了和大家聊聊。2. 整体架构设计与技术选型考量2.1 业务架构与模块划分社区医疗的业务看似琐碎但梳理后核心模块非常清晰。我们将其划分为四大中心患者服务中心这是面向居民的窗口核心是居民电子健康档案EHR的全生命周期管理以及预约挂号、在线咨询、报告查询等功能。难点在于EHR的数据结构设计要能灵活兼容个人基本信息、历次就诊记录、慢病随访数据、体检报告、过敏史等异构信息。诊疗业务中心支撑医生日常工作的核心包括门诊病历书写考虑结构化录入以提高数据质量、处方开具与药品库存、合理用药规则库联动、检验检查申请与报告归集。这里的关键是业务流程的闭环管理和不同角色医生、护士、药师的协同。运营管理中心这是平台的“后台后台”涵盖药品与医疗器械的进销存管理、医护人员排班、绩效核算、财务收支统计等。库存管理需要实现批次号、效期跟踪预警临期药品这是社区药房管理的刚需。数据统计中心不单是简单的报表查询而是基于业务数据为管理者提供决策支持如常见病发病趋势分析、药品使用分析、居民健康覆盖率统计等。初期可能用静态报表但架构上要为后续的数据分析预留接口。2.2 技术栈选型详解为什么是SpringBoot 2.x而不是其他在当时现在也依然适用的背景下这是一个平衡了效率、生态和可控性的最佳选择。核心框架SpringBoot 2.3.5。这个版本稳定生态丰富。我们用它来快速集成以下几乎所有组件通过spring-boot-starter-*依赖极大简化了配置。持久层MyBatis-Plus。放弃原生MyBatis和JPA选择MyBatis-Plus主要是看中了其强大的CRUD封装和条件构造器。社区医疗业务中复杂动态查询如组合条件筛选居民档案、多维度统计报表非常多MyBatis-Plus的QueryWrapper写起来非常高效。它的代码生成器也能一键生成实体、Mapper、Service基础代码对于有大量标准增删改查的业务表如药品目录、科室信息来说开发效率提升显著。安全与权限Spring Security JWT。社区医疗系统必须区分管理员、医生、护士、药师、居民等多种角色且数据权限要精细到医生只能看自己科室或自己负责的患者。Spring Security提供了强大的认证授权框架结合JWT实现无状态令牌适合前后端分离架构。我们自定义了UserDetailsService和权限注解实现了基于URL和数据的动态权限控制。缓存Redis。主要用于两类场景一是缓存高频访问但不常变的数据如系统配置项、药品分类字典二是用作门诊高并发场景下的“减震器”比如预约号源库存的扣减通过Redis的原子操作如DECR可以有效防止超卖。消息队列RabbitMQ。用于解耦耗时操作和提升用户体验。例如居民成功预约后需要异步发送短信提醒医生开具检查单后需要异步通知检验科室。这些都用消息队列来实现避免主线程阻塞。数据库MySQL 5.7。关系型数据库是业务数据的主存储满足事务一致性要求。我们针对核心表如health_record健康档案、medical_order医嘱做了重点索引优化。注意技术选型切忌“炫技”。在资源有限的社区医疗场景稳定、可维护、社区活跃度高的技术栈远比“最新最潮”更重要。例如我们当时没有引入复杂的微服务而是采用单体架构多模块的方式因为项目初期用户量和并发并不高微服务带来的运维复杂度反而会成为负担。3. 核心功能模块实现解析3.1 居民电子健康档案EHR模块设计这是系统的基石。EHR不是一张简单的表而是一个以个人为核心的数据聚合体。1. 数据库设计我们采用“主表扩展表”的灵活设计。resident表存储居民核心身份信息ID、姓名、身份证号、联系方式、常住地址等。health_record表作为档案主表与resident一对一关联记录档案ID、建档时间、责任医生等。多个业务子表通过health_record_id与档案主表关联。例如clinic_visit门诊就诊记录。chronic_disease_followup慢病随访记录。vaccination_record预防接种记录。physical_exam_report体检报告这里可以存储报告PDF的OSS路径或结构化数据。这种设计的好处是结构清晰易于扩展。当需要新增一类健康记录如中医体质辨识时只需新增一张表不影响原有结构。2. 关键接口实现档案的“增删改查”中“查”是最复杂的。我们提供了一个强大的复合查询接口。RestController RequestMapping(/api/ehr) public class EhrController { Autowired private EhrService ehrService; GetMapping(/list) public PageResultResidentEhrVO listResidentEhr(ResidentQueryDTO queryDTO) { // 使用MyBatis-Plus的QueryWrapper构建动态查询条件 QueryWrapperResident wrapper new QueryWrapper(); if (StringUtils.isNotBlank(queryDTO.getName())) { wrapper.like(name, queryDTO.getName()); } if (StringUtils.isNotBlank(queryDTO.getIdNumber())) { wrapper.eq(id_number, queryDTO.getIdNumber()); } if (queryDTO.getChronicDiseaseType() ! null) { // 关联查询慢病表存在对应慢病记录的居民 wrapper.exists(SELECT 1 FROM chronic_disease_followup c WHERE c.resident_id resident.id AND c.disease_type {0}, queryDTO.getChronicDiseaseType()); } // ... 其他条件 wrapper.orderByDesc(create_time); IPageResident page residentMapper.selectPage(new Page(queryDTO.getPageNum(), queryDTO.getPageSize()), wrapper); // 将PageResident 转换为 PageResultResidentEhrVO并聚合关联的健康档案摘要信息 return ehrService.convertToEhrVOPage(page); } }3. 实操心得数据脱敏在查询和展示居民列表时身份证号、手机号等敏感信息必须进行部分掩码处理如110101****1234这在Service层返回VO对象时就要做好。档案合并现实中会遇到一人多档的情况。我们设计了一个“档案合并”后台任务基于身份证号、姓名等规则识别疑似重复档案经管理员确认后将次要档案的历史数据迁移到主档案下并逻辑删除次要档案。这个过程必须记录详细日志保证数据可追溯。3.2 药品库存管理模块实现社区药房的库存管理核心在于“精准”和“预警”。1. 核心表结构drug药品基础信息表药品编码、通用名、商品名、规格、厂家、单价等。drug_inventory库存表与drug关联。关键字段包括batch_number批号、expiry_date有效期至、stock_quantity当前库存、locked_quantity锁定库存如已开处方但未发放。inbound_order/outbound_order入库单/出库单记录每一次库存变动的明细、经手人、时间。2. 库存扣减逻辑——防止超发这是核心并发控制点。医生开处方时系统会预先检查并锁定库存。发药时再进行实际扣减。Service Transactional(rollbackFor Exception.class) public class InventoryServiceImpl implements InventoryService { Override public boolean lockInventory(Long drugId, String batchNumber, Integer quantity) { // 1. 使用乐观锁或悲观锁查询并锁定库存 DrugInventory inventory drugInventoryMapper.selectForUpdate(drugId, batchNumber); // 悲观锁写法 if (inventory null || inventory.getAvailableQuantity() quantity) { throw new BusinessException(药品库存不足); } // 2. 更新锁定数量 inventory.setLockedQuantity(inventory.getLockedQuantity() quantity); return drugInventoryMapper.updateById(inventory) 0; } Override public boolean reduceInventory(Long outboundOrderId) { // 根据出库单明细减少实际库存并清除对应的锁定库存 ListOutboundDetail details detailMapper.selectByOrderId(outboundOrderId); for (OutboundDetail detail : details) { DrugInventory inventory drugInventoryMapper.selectById(detail.getInventoryId()); inventory.setStockQuantity(inventory.getStockQuantity() - detail.getQuantity()); inventory.setLockedQuantity(inventory.getLockedQuantity() - detail.getQuantity()); drugInventoryMapper.updateById(inventory); // 记录库存变更流水 inventoryFlowMapper.insert(new InventoryFlow(...)); } return true; } }3. 效期预警实现我们通过一个定时任务使用SpringScheduled每天凌晨扫描drug_inventory表。Component public class DrugExpiryWarningTask { Autowired private DrugInventoryMapper inventoryMapper; Autowired private NotificationService notificationService; Scheduled(cron 0 0 2 * * ?) // 每天凌晨2点执行 public void checkExpiry() { // 查询距离过期还有30天、7天的药品 LocalDate warningDate30 LocalDate.now().plusDays(30); LocalDate warningDate7 LocalDate.now().plusDays(7); ListDrugInventory expiringSoonList inventoryMapper.selectExpiringSoon(warningDate30); for (DrugInventory item : expiringSoonList) { // 构建预警消息推送给药房管理员站内信、短信等 String message String.format(药品【%s】批号%s将于%s过期当前库存%s。, item.getDrugName(), item.getBatchNumber(), item.getExpiryDate(), item.getStockQuantity()); notificationService.sendToPharmacist(message, item); } } }踩坑记录初期我们只在出库时按效期优先先过期先出的原则排序但没有主动预警。结果导致一次盘点时发现了一批临近过期的慢性病用药处理起来非常被动。所以主动预警机制必须作为库存管理的标配。3.3 统一权限控制设计与实现多角色、细粒度权限是管理系统的灵魂。我们采用经典的RBAC角色-权限模型并进行了数据权限扩展。1. 数据库表设计sys_user用户表。sys_role角色表如超级管理员、社区站长、全科医生、护士、药师。sys_menu菜单/权限表对应前端路由和API接口。sys_user_role用户-角色关联表。sys_role_menu角色-菜单关联表。sys_data_scope数据权限规则表扩展用于控制用户能看到哪些数据如医生只能看本社区的患者。2. 核心配置类在Spring Security配置中我们自定义了访问决策逻辑。Configuration EnableGlobalMethodSecurity(prePostEnabled true) // 启用方法级注解 public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers(/api/auth/login).permitAll() .antMatchers(/api/**).authenticated() // 所有/api请求需要认证 .anyRequest().permitAll() .and() .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); } Bean public JwtAuthenticationFilter jwtAuthenticationFilter() { return new JwtAuthenticationFilter(); } }3. 数据权限拦截这是难点。我们在MyBatis层面通过插件Interceptor实现。为需要数据权限的Mapper方法自动添加SQL条件。Intercepts({Signature(type Executor.class, method prepare, args {Connection.class, Integer.class})}) Component public class DataScopeInterceptor implements Interceptor { Override public Object intercept(Invocation invocation) throws Throwable { StatementHandler handler (StatementHandler) invocation.getTarget(); MetaObject metaObject SystemMetaObject.forObject(handler); MappedStatement mappedStatement (MappedStatement) metaObject.getValue(delegate.mappedStatement); // 1. 判断该方法是否需要数据权限过滤通过自定义注解DataScope DataScope dataScope getDataScopeAnnotation(mappedStatement); if (dataScope ! null) { // 2. 获取当前登录用户的信息 UserDetails userDetails SecurityContextHolder.getContext().getAuthentication().getPrincipal(); // 3. 根据用户角色拼接额外的SQL条件例如AND community_id #{user.communityId} String originalSql (String) metaObject.getValue(delegate.boundSql.sql); String newSql addDataScopeCondition(originalSql, userDetails, dataScope); metaObject.setValue(delegate.boundSql.sql, newSql); } return invocation.proceed(); } }4. 实操心得权限缓存用户的菜单权限和API权限在登录时加载并存入Redis设置合理的过期时间。每次鉴权时从缓存读取避免频繁查询数据库。按钮级控制前端按钮的显示/隐藏可以通过后端返回的权限标识列表来控制。我们定义了一个/api/auth/permissions接口返回当前用户的所有权限码。日志记录所有敏感操作如删除居民档案、修改药品库存、查看敏感健康信息都必须记录详细的操作日志谁、何时、做了什么、IP地址这是安全审计的底线。4. 前后端分离与API设计规范我们采用前后端分离架构前端使用Vue.js后端提供纯RESTful API。4.1 统一的响应体封装为了保证前端处理的一致性所有API响应都包装在一个标准格式中。Data public class RT implements Serializable { private Integer code; // 状态码200成功其他为错误 private String msg; // 提示信息 private T data; // 响应数据 public static T RT ok(T data) { RT r new R(); r.setCode(200); r.setMsg(操作成功); r.setData(data); return r; } public static T RT error(String msg) { RT r new R(); r.setCode(500); r.setMsg(msg); return r; } // 更多预定义状态码... }通过一个全局的RestControllerAdvice对控制器异常进行统一处理将各类异常业务异常、参数校验异常、系统异常转换为统一的R对象返回。4.2 API文档与接口测试我们集成Swagger2现为Swagger3 / OpenAPI 3来自动生成API文档。在SpringBoot中配置非常简单Configuration EnableSwagger2 public class SwaggerConfig { Bean public Docket createRestApi() { return new Docket(DocumentationType.SWAGGER_2) .apiInfo(apiInfo()) .select() .apis(RequestHandlerSelectors.basePackage(com.zhongshan.platform.controller)) .paths(PathSelectors.any()) .build() .securitySchemes(securitySchemes()) // 配置JWT认证 .securityContexts(securityContexts()); } private ApiInfo apiInfo() { return new ApiInfoBuilder() .title(中山社区医疗综合服务平台API文档) .description(社区医疗管理系统后端接口说明) .version(1.0) .build(); } }这样启动项目后访问http://localhost:8080/swagger-ui.html就能看到所有接口的详细说明支持在线测试极大方便了前后端联调。4.3 前端与后端的协作要点接口联调利用Swagger文档前端开发者可以独立进行接口测试减少对后端的依赖。后端应保证接口的稳定性和文档的准确性。跨域问题在开发环境我们通过CrossOrigin注解或全局配置解决。在生产环境则通过Nginx反向代理来规避。文件上传对于体检报告、证件照等文件上传我们使用阿里云OSS等对象存储服务。后端接口只接收文件并上传至OSS然后将文件的访问URL返回给前端存储。这样做避免了服务器磁盘空间和带宽的压力。5. 部署、监控与性能优化实践5.1 多环境部署配置SpringBoot的application-{profile}.properties机制完美支持多环境。我们通常有application-dev.properties开发环境连接本地数据库。application-test.properties测试环境连接测试服务器。application-prod.properties生产环境配置正式数据库、Redis等地址。通过启动命令java -jar app.jar --spring.profiles.activeprod来激活对应环境配置。5.2 数据库性能优化随着数据量增长查询变慢是必然的。我们采取了以下措施索引优化使用EXPLAIN分析慢查询SQL为WHERE、ORDER BY、GROUP BY子句中的字段建立合适索引。例如在clinic_visit表的resident_id和visit_date上建立复合索引加速按居民和日期范围的查询。SQL语句优化避免SELECT *只取需要的字段谨慎使用JOIN尤其是多表关联和大表关联大量数据分页查询使用“延迟关联”优化。归档历史数据将超过3年的门诊详细记录迁移到历史归档表主表只保留近期数据显著提升核心业务查询速度。5.3 应用监控与日志健康检查Spring Boot Actuator 提供了/actuator/health端点可以集成到运维监控平台实时了解应用状态数据库连接、磁盘空间等。日志聚合使用Logback或Log4j2配置日志按天滚动存储。关键业务操作如处方开立、库存修改和异常错误必须打印详细日志。生产环境推荐将日志收集到ELKElasticsearch, Logstash, Kibana或Graylog等平台便于集中查询和分析。JVM监控在启动脚本中配置JVM参数如堆内存大小、GC日志输出。使用VisualVM、JConsole或Arthas等工具在需要时进行诊断。5.4 应对高并发场景的思考虽然社区医疗系统并发峰值不会像互联网应用那么夸张但在集中预约如流感疫苗接种预约时仍可能面临压力。缓存策略升级对于号源库存这种极端热点数据除了用Redis还可以考虑使用Redis分布式锁或Lua脚本保证原子性防止超卖。数据库连接池优化合理配置HikariCP等连接池参数最大连接数、最小空闲连接、连接超时时间避免连接耗尽或浪费。异步化处理将所有非实时核心的操作异步化。例如预约成功后的短信通知、数据统计报表的生成都通过消息队列发送到后台任务异步执行快速释放请求线程提升接口响应速度。6. 项目复盘与避坑指南回顾整个项目有几个关键点值得后来者特别注意需求理解的深度决定代码的复杂度初期和业务方医生、护士、管理员的沟通至关重要。不要想当然。比如“排班”功能不仅要考虑医生还要考虑护士、诊室、设备并且要处理调班、替班、节假日等复杂规则。我们第一版做得太简单后来返工代价很大。字典数据的管理像“疾病编码”、“药品分类”、“收费项目”这类字典数据一定要设计成可后台配置的不要硬编码在代码或枚举里。我们单独做了一个“数据字典”管理模块方便后续维护和扩展。事务边界要清晰一个业务操作可能涉及多张表的更新如开处方扣库存、生成订单、写病历。务必使用Spring的Transactional声明事务并仔细考虑事务的传播行为和回滚条件。对于分布式环境如后期拆服务需要考虑分布式事务方案如Seata但在单体架构下数据库事务足够了。代码的可读性与可维护性坚持良好的编码规范。我们要求Service层方法名必须清晰表达业务意图复杂的业务逻辑要抽取私有方法或独立工具类。大量使用DTOData Transfer Object进行前后端数据交互避免直接暴露数据库实体。这为后续可能的系统升级或重构减少了大量麻烦。安全无小事SQL注入坚持使用MyBatis的#{}预编译严禁字符串拼接SQL。XSS攻击对用户输入的内容如病历主诉进行转义或过滤或者在前端渲染时使用安全的文本绑定方式如Vue的{{ }}默认已转义。越权访问除了菜单权限数据权限校验必须贯穿始终。每次查询、修改、删除前都要在服务层显式校验当前用户是否有权操作目标数据。密码安全用户密码必须加盐哈希存储使用BCryptPasswordEncoder绝对禁止明文存储。这个项目从设计到上线历时近半年是一个典型的“业务驱动”型后端管理系统开发案例。它没有用到太多炫酷的新技术但把SpringBoot生态下的经典组件用扎实、用透彻稳稳地支撑起了社区医疗的日常运转。对于想深入理解如何将一个复杂的线下业务流程通过代码转化为一个稳定、易用的线上系统的朋友来说这类项目的实战价值非常高。源码本身是骨架而背后的业务思考、架构权衡和细节处理才是真正的血肉。本文还有配套的精品资源点击获取