简介本资源为基于Java与SpringBoot的中山社区医疗综合服务平台完整设计与实现代码面向计算机专业学生、Java后端初学者及需要医疗管理系统参考方案的开发者可用于毕业设计、课程设计或二次开发学习。项目采用前后端分离架构后端以SpringBoot为核心整合MyBatisPlus、MySQL与Maven前端使用Vue配合ElementUI、Ajax实现交互涵盖用户信息管理、图片素材与视频素材等模块并附有从绪论、相关技术介绍、系统分析、系统设计到系统实现的完整文档结构便于理解B/S架构下的开发流程。压缩包共416个文件包含109个Java源码、58个Vue组件、161个SVG图标、17个JavaScript脚本及PNG、JPG图片、XML配置、CSS样式等整体约28.9MB另附bat启动脚本与说明文档方便快速部署运行。目前已有77人学习下载适合希望掌握SpringBoot医疗类管理系统开发思路的读者参考借鉴。1. 中山社区医疗综合服务平台一个 SpringBoot 管理系统的落地拆解社区医疗这个场景真正做过的人都知道难点从来不在“能不能写个增删改查”而在“居民档案、慢病随访、门诊挂号、药品库存这几摊子数据怎么在一个系统里不打架”。中山社区医疗综合服务平台这个标题本质上是给一个典型的 Java SpringBoot 后台管理系统套上了社区医疗的业务外壳。它要解决的是社区卫生院、个体门诊、街道卫生服务中心这类中小机构的信息化问题——患者信息散在纸质本上、随访记录靠 Excel、药品进销存对不上账。适合谁看一是做 Java 课程设计或毕设、需要一套完整管理系统源码练手的学生二是中小医疗机构里懂点技术、想自己搭一套内部系统的运维或负责人。这一章先把业务边界和技术选型讲清楚后面几章直接上代码和配置。社区医疗的业务模型其实比很多人想的要复杂。一个居民在系统里既是“患者”也可能是“慢病管理对象”还可能是“签约家庭医生服务的成员”。这三重身份如果各自建表、各自维护数据一致性立刻崩。常见做法是围绕“居民主索引”建一张核心表其他业务表通过居民 ID 关联挂号、随访、用药记录都挂在这个 ID 下面。SpringBoot 在这里的价值不是“流行”而是它的分层结构天然适合把 controller、service、mapper 拆开社区医疗这种业务规则多、字段杂的场景拆开之后改一个随访逻辑不会牵动挂号模块。数据库一般选 MySQL中小社区的数据量几千到几万居民完全扛得住没必要上分布式。前端用 Vue3 后台管理系统模板或者 Thymeleaf 服务端渲染都行前者适合前后端分离、后者适合快速出活。下面几章我会按“建表 → 搭框架 → 写核心业务 → 排坑 → 进阶”的顺序把一套能跑起来的方案讲透。2. 从居民主索引到随访记录数据表怎么设计才不返工2.1 为什么先定居民主索引而不是先写 Controller很多人拿到管理系统需求第一反应是打开 IDE 建 SpringBoot 项目、写 Controller。这是典型的返工起点。社区医疗的业务实体关系是一个居民对应多条挂号记录、多条随访记录、多条用药记录还可能对应一个家庭医生签约关系。如果居民表设计得随意比如用身份证号当主键、或者把姓名和电话直接冗余到每张业务表后面做数据统计和跨表查询时会非常痛苦。我一般会先画三张核心表resident居民主索引、visit_record就诊/挂号记录、follow_up随访记录。居民主索引只存最基础、最稳定的信息系统内部 ID、姓名、性别、出生日期、身份证号加密存储、联系电话、所属社区。注意这里用自增或雪花算法生成的内部 ID 做主键身份证号只做唯一索引因为身份证号可能录入错误需要修改而主键一旦被业务表引用就不该变。CREATE TABLE resident ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 内部主键, name VARCHAR(50) NOT NULL COMMENT 姓名, gender TINYINT DEFAULT 0 COMMENT 0未知 1男 2女, birth_date DATE COMMENT 出生日期, id_card VARCHAR(64) COMMENT 身份证号加密存储, phone VARCHAR(20) COMMENT 联系电话, community_code VARCHAR(20) COMMENT 所属社区编码, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_id_card (id_card), KEY idx_community (community_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT居民主索引;这段建表语句里id_card字段长度给到 64 是为了存加密后的密文不是存明文 18 位。community_code加普通索引是因为社区医疗系统最常见的查询就是“按社区筛选居民列表”。utf8mb4字符集必须显式指定否则姓名里的生僻字会变成问号这个坑我在实际项目里踩过不止一次。2.2 随访记录表的外键与状态字段设计随访是社区医疗区别于普通门诊系统的核心业务。一个高血压居民可能每季度随访一次随访内容包括血压、血糖、用药依从性、下次随访日期。随访记录表的设计要点有两个一是用resident_id关联主索引二是加一个status字段标记随访状态待随访、已完成、已失访。CREATE TABLE follow_up ( id BIGINT PRIMARY KEY AUTO_INCREMENT, resident_id BIGINT NOT NULL COMMENT 关联居民主索引, follow_type VARCHAR(20) COMMENT 随访类型高血压/糖尿病/老年人, systolic INT COMMENT 收缩压, diastolic INT COMMENT 舒张压, fasting_glucose DECIMAL(5,2) COMMENT 空腹血糖, next_date DATE COMMENT 下次随访日期, status TINYINT DEFAULT 0 COMMENT 0待随访 1已完成 2失访, doctor_id BIGINT COMMENT 随访医生, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_resident (resident_id), KEY idx_next_date (next_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT随访记录;next_date加索引是为了支持“查询本周需要随访的居民”这个高频操作。status用 TINYINT 而不是字符串是因为状态值固定且查询频繁整型比较更快。这里不建物理外键用逻辑外键加索引原因是社区医疗系统经常需要批量导入历史数据物理外键会让导入变得极其麻烦而且后期分库分表时外键是累赘。这是很多教程不会告诉你的取舍。2.3 药品库存表的批次管理社区医疗平台通常还带一个简易的药品进销存。药品和普通商品最大的区别是批次和效期。同一盒阿莫西林不同批次的效期不同出库时必须按效期优先。所以库存表不能只存一个总数要按批次存。CREATE TABLE drug_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, drug_id BIGINT NOT NULL COMMENT 药品字典ID, batch_no VARCHAR(50) COMMENT 生产批号, quantity INT DEFAULT 0 COMMENT 当前批次库存, expire_date DATE COMMENT 有效期至, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_drug (drug_id), KEY idx_expire (expire_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT药品批次库存;出库时的逻辑是SELECT * FROM drug_stock WHERE drug_id? AND quantity0 ORDER BY expire_date ASC LIMIT 1先出快过期的。这个逻辑看起来简单但如果不按批次建表后期想实现效期预警和先进先出就只能推倒重来。表设计阶段多花两小时编码阶段省两天这是血泪经验。3. SpringBoot 项目骨架搭建依赖、配置与分层3.1 pom.xml 里真正需要哪些依赖网上很多 SpringBoot 教程一上来就堆几十个依赖其实社区医疗管理系统核心依赖就那么几个。下面是我一般会用的最小集合。dependencies !-- Web 层提供 REST 接口和 MVC -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MyBatis-Plus比原生 MyBatis 少写大量 XML -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency !-- MySQL 驱动 -- dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency !-- 参数校验随访表单字段多必须校验 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency !-- Lombok减少 getter/setter 噪音 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependenciesMyBatis-Plus 的版本我写的是 3.5.3.1这个版本和 SpringBoot 2.7.x 搭配稳定。如果你用的是 SpringBoot 3.x注意 MyBatis-Plus 需要换到 3.5.3.2 以上否则启动会报NoClassDefFoundError。这是“springboot版本太高”这个热搜词背后的真实痛点——版本不匹配导致的启动失败排查起来很费时间。3.2 application.yml 的关键配置项配置文件里最容易出问题的是数据库连接和 MyBatis-Plus 的映射策略。社区医疗系统的字段名通常是下划线风格如id_card而 Java 实体是驼峰idCard必须开启驼峰映射。spring: datasource: url: jdbc:mysql://localhost:3306/community_medical?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0serverTimezoneAsia/Shanghai必须加否则插入的时间会差 8 小时随访日期算错一天在医疗场景里是严重问题。logic-delete-field配置了逻辑删除居民档案和随访记录都不应该物理删除这是医疗数据的基本要求。注意逻辑删除字段deleted需要在每张表里都加上默认值 0。3.3 分层结构Controller 薄、Service 厚SpringBoot 项目最常见的分层错误是把业务逻辑写在 Controller 里。社区医疗的业务规则比如“随访日期不能早于上次随访日期”“药品出库不能超过批次库存”必须放在 Service 层Controller 只做参数接收和结果返回。RestController RequestMapping(/api/follow-up) RequiredArgsConstructor public class FollowUpController { private final FollowUpService followUpService; PostMapping public ResultLong create(RequestBody Valid FollowUpDTO dto) { return Result.ok(followUpService.createFollowUp(dto)); } GetMapping(/pending) public ResultListFollowUpVO pendingList(RequestParam String communityCode) { return Result.ok(followUpService.listPending(communityCode)); } }Controller 里没有一行业务判断Valid触发 DTO 上的校验注解Result是统一返回包装。Service 层才去检查“该居民上次随访是否已完成”“next_date 是否合理”。这种分层在项目初期看不出好处但当社区医疗的业务规则从 5 条涨到 50 条时改 Service 不会影响接口签名前端不用跟着改。这是管理系统能长期维护的关键。4. 核心业务实现随访提醒、药品出库与数据一致性4.1 随访提醒的定时任务与查询优化社区医疗平台最实用的功能之一是“待随访列表”。实现方式有两种一是每次查询时实时计算二是用定时任务预生成待办。数据量小的时候实时查询没问题但居民上万后每次打开首页都全表扫描会明显变慢。Service RequiredArgsConstructor public class FollowUpServiceImpl extends ServiceImplFollowUpMapper, FollowUp implements FollowUpService { Override public ListFollowUpVO listPending(String communityCode) { LocalDate today LocalDate.now(); LocalDate sevenDaysLater today.plusDays(7); return baseMapper.selectPendingList(communityCode, today, sevenDaysLater); } }对应的 Mapper XML 里查询条件是next_date BETWEEN #{today} AND #{sevenDaysLater} AND status 0并且resident表按community_code过滤。这里的关键是next_date上的索引必须命中否则数据量上来后查询会从毫秒级掉到秒级。我一般会在上线前用EXPLAIN确认执行计划看到typerange才放心。4.2 药品出库的并发扣减别用“查完再减”药品出库是社区医疗系统里少数有并发风险的场景。两个药房窗口同时给同一个批次出库如果代码写成“先 SELECT 查库存再 UPDATE 减库存”并发下会超卖。Transactional(rollbackFor Exception.class) public void outbound(Long drugId, int quantity) { // 按效期优先取可用批次 DrugStock stock drugStockMapper.selectAvailableBatch(drugId); if (stock null || stock.getQuantity() quantity) { throw new BizException(库存不足); } // 带条件的原子扣减quantity 出库量才更新 int affected drugStockMapper.reduceStock(stock.getId(), quantity); if (affected 0) { throw new BizException(库存扣减失败请重试); } }reduceStock的 SQL 是UPDATE drug_stock SET quantity quantity - #{quantity} WHERE id #{id} AND quantity #{quantity}。这个AND quantity #{quantity}就是防超卖的关键数据库行锁保证同一批次不会被扣成负数。Transactional保证扣减和出库记录写入在同一个事务里。这是“java怎么保证数据一致性”这个热搜词在社区医疗场景下的具体答案——不是靠分布式事务而是靠数据库行锁加条件更新。4.3 居民档案的批量导入与 XSS 过滤社区医疗系统上线时历史居民数据通常是一堆 Excel。用 Java POI 解析 Excel 导入是常见做法。但这里有个容易忽略的安全问题如果导入的姓名或地址字段里带了script标签前端渲染时可能触发 XSS。热搜词里“springboot项目全局过滤器处理上传pdf文件时xss攻击”说的就是这类问题。Component public class XssFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; // 只对写操作做参数清洗读操作放行减少开销 if (POST.equalsIgnoreCase(req.getMethod()) || PUT.equalsIgnoreCase(req.getMethod())) { chain.doFilter(new XssRequestWrapper(req), response); } else { chain.doFilter(request, response); } } }XssRequestWrapper继承HttpServletRequestWrapper在getParameter里对值做 HTML 转义。注意不要对所有请求都清洗GET 查询参数清洗会影响性能且没必要。导入的 Excel 数据在写入数据库前Service 层也要做一次转义因为过滤器只处理 HTTP 参数不处理 POI 解析出来的字符串。这两层防护缺一不可。5. 避坑与排查社区医疗系统上线后最容易翻车的五件事5.1 现象随访日期插入后差一天原因MySQL 连接串没配serverTimezone或者 Jackson 序列化时区没设。Java 的LocalDate在默认时区下转成java.sql.Date时可能偏移。解决连接串加serverTimezoneAsia/Shanghaiapplication.yml里配spring.jackson.time-zone: GMT8实体类日期字段统一用LocalDate而不是java.util.Date。5.2 现象居民列表分页查询越来越慢原因resident表数据到几万条后LIMIT偏移量大的分页会全表扫描。另外如果community_code没索引按社区筛选会走全表。解决community_code加索引分页改用“上一页最后一条 ID”的游标方式或者用 MyBatis-Plus 的分页插件配合覆盖索引。如果必须用LIMIT offset确保ORDER BY的字段有索引。5.3 现象药品库存出现负数原因出库代码用了“先查再减”的非原子操作并发下两个请求都查到库存充足然后都执行了扣减。解决改成UPDATE ... WHERE quantity ?的条件更新检查 affected rows。如果 affected 为 0 就抛异常回滚。这个改动很小但能彻底解决超卖。5.4 现象SpringBoot 启动报Failed to configure a DataSource原因pom.xml里引入了mybatis-plus-boot-starter但没配数据库连接或者 MySQL 驱动版本和数据库版本不匹配。SpringBoot 3.x 下 MySQL 驱动必须是com.mysql.cj.jdbc.Driver老版本com.mysql.jdbc.Driver已废弃。解决确认application.yml里spring.datasource配置完整SpringBoot 3.x 用mysql-connector-j而不是mysql-connector-java检查驱动类名。5.5 现象导入 Excel 后姓名显示为问号原因数据库字符集不是utf8mb4或者 JDBC 连接串没加characterEncodingutf8mb4。解决建表时显式指定DEFAULT CHARSETutf8mb4连接串加useUnicodetruecharacterEncodingutf8mb4POI 读取时确认Workbook的编码设置。生僻字在社区医疗场景很常见这个坑必须提前堵上。6. 进阶技巧用逻辑删除和操作日志把系统做成“有后悔药”的社区医疗系统的数据敏感度比普通管理系统高一个量级。居民档案删错了、随访记录改错了如果没有追溯手段就是医疗纠纷的隐患。我一般会在项目里加两个东西逻辑删除和操作日志。逻辑删除前面配置里已经提过deleted字段配合 MyBatis-Plus 的TableLogic注解删除操作自动变成UPDATE deleted1查询自动过滤。但光有逻辑删除还不够因为逻辑删除只告诉你“这条没了”不告诉你“谁在什么时候删的”。操作日志我一般用 AOP 加自定义注解实现。在 Service 方法上标OpLog(module随访, action修改)切面里拦截把操作人、操作时间、方法名、参数摘要写进operation_log表。参数摘要不要存完整 JSON只存关键字段比如随访记录的 ID 和变更前后的状态值。这样查问题时能快速定位又不会让日志表膨胀得太快。Aspect Component public class OpLogAspect { Around(annotation(opLog)) public Object around(ProceedingJoinPoint pjp, OpLog opLog) throws Throwable { Object result pjp.proceed(); // 只记录成功操作异常由全局异常处理器记录 logService.save(opLog.module(), opLog.action(), pjp.getArgs()); return result; } }这个切面要注意两点一是只记录成功返回的操作失败的操作在全局异常处理器里记避免重复二是参数摘要要做脱敏身份证号和电话不能进日志表。另外操作日志表要按月分表或者定期归档社区医疗系统跑一年下来日志量不小。还有一个实用技巧是给关键业务表加version字段做乐观锁。随访记录修改时带上版本号UPDATE ... WHERE id? AND version?如果 affected 为 0 说明有人在你之前改了提示用户刷新重试。这在多人同时操作同一个居民档案时能避免覆盖。乐观锁不是万能的但在社区医疗这种并发不高的场景里比悲观锁轻量得多。最后说一个我自己的习惯每次上线新功能前先在测试库跑一遍“删除居民 → 查随访记录 → 查操作日志”这条链路确认逻辑删除生效、日志有记录、数据能追溯。这个习惯帮我省过好几次“后悔药”。社区医疗系统的技术难度不在代码多复杂而在数据要经得起查、改错了要能还原。希望帮到你。本文还有配套的精品资源点击获取 SpringBoot社区医疗管理系统实战：表设计、分层与避坑
简介本资源为基于Java与SpringBoot的中山社区医疗综合服务平台完整设计与实现代码面向计算机专业学生、Java后端初学者及需要医疗管理系统参考方案的开发者可用于毕业设计、课程设计或二次开发学习。项目采用前后端分离架构后端以SpringBoot为核心整合MyBatisPlus、MySQL与Maven前端使用Vue配合ElementUI、Ajax实现交互涵盖用户信息管理、图片素材与视频素材等模块并附有从绪论、相关技术介绍、系统分析、系统设计到系统实现的完整文档结构便于理解B/S架构下的开发流程。压缩包共416个文件包含109个Java源码、58个Vue组件、161个SVG图标、17个JavaScript脚本及PNG、JPG图片、XML配置、CSS样式等整体约28.9MB另附bat启动脚本与说明文档方便快速部署运行。目前已有77人学习下载适合希望掌握SpringBoot医疗类管理系统开发思路的读者参考借鉴。1. 中山社区医疗综合服务平台一个 SpringBoot 管理系统的落地拆解社区医疗这个场景真正做过的人都知道难点从来不在“能不能写个增删改查”而在“居民档案、慢病随访、门诊挂号、药品库存这几摊子数据怎么在一个系统里不打架”。中山社区医疗综合服务平台这个标题本质上是给一个典型的 Java SpringBoot 后台管理系统套上了社区医疗的业务外壳。它要解决的是社区卫生院、个体门诊、街道卫生服务中心这类中小机构的信息化问题——患者信息散在纸质本上、随访记录靠 Excel、药品进销存对不上账。适合谁看一是做 Java 课程设计或毕设、需要一套完整管理系统源码练手的学生二是中小医疗机构里懂点技术、想自己搭一套内部系统的运维或负责人。这一章先把业务边界和技术选型讲清楚后面几章直接上代码和配置。社区医疗的业务模型其实比很多人想的要复杂。一个居民在系统里既是“患者”也可能是“慢病管理对象”还可能是“签约家庭医生服务的成员”。这三重身份如果各自建表、各自维护数据一致性立刻崩。常见做法是围绕“居民主索引”建一张核心表其他业务表通过居民 ID 关联挂号、随访、用药记录都挂在这个 ID 下面。SpringBoot 在这里的价值不是“流行”而是它的分层结构天然适合把 controller、service、mapper 拆开社区医疗这种业务规则多、字段杂的场景拆开之后改一个随访逻辑不会牵动挂号模块。数据库一般选 MySQL中小社区的数据量几千到几万居民完全扛得住没必要上分布式。前端用 Vue3 后台管理系统模板或者 Thymeleaf 服务端渲染都行前者适合前后端分离、后者适合快速出活。下面几章我会按“建表 → 搭框架 → 写核心业务 → 排坑 → 进阶”的顺序把一套能跑起来的方案讲透。2. 从居民主索引到随访记录数据表怎么设计才不返工2.1 为什么先定居民主索引而不是先写 Controller很多人拿到管理系统需求第一反应是打开 IDE 建 SpringBoot 项目、写 Controller。这是典型的返工起点。社区医疗的业务实体关系是一个居民对应多条挂号记录、多条随访记录、多条用药记录还可能对应一个家庭医生签约关系。如果居民表设计得随意比如用身份证号当主键、或者把姓名和电话直接冗余到每张业务表后面做数据统计和跨表查询时会非常痛苦。我一般会先画三张核心表resident居民主索引、visit_record就诊/挂号记录、follow_up随访记录。居民主索引只存最基础、最稳定的信息系统内部 ID、姓名、性别、出生日期、身份证号加密存储、联系电话、所属社区。注意这里用自增或雪花算法生成的内部 ID 做主键身份证号只做唯一索引因为身份证号可能录入错误需要修改而主键一旦被业务表引用就不该变。CREATE TABLE resident ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 内部主键, name VARCHAR(50) NOT NULL COMMENT 姓名, gender TINYINT DEFAULT 0 COMMENT 0未知 1男 2女, birth_date DATE COMMENT 出生日期, id_card VARCHAR(64) COMMENT 身份证号加密存储, phone VARCHAR(20) COMMENT 联系电话, community_code VARCHAR(20) COMMENT 所属社区编码, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_id_card (id_card), KEY idx_community (community_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT居民主索引;这段建表语句里id_card字段长度给到 64 是为了存加密后的密文不是存明文 18 位。community_code加普通索引是因为社区医疗系统最常见的查询就是“按社区筛选居民列表”。utf8mb4字符集必须显式指定否则姓名里的生僻字会变成问号这个坑我在实际项目里踩过不止一次。2.2 随访记录表的外键与状态字段设计随访是社区医疗区别于普通门诊系统的核心业务。一个高血压居民可能每季度随访一次随访内容包括血压、血糖、用药依从性、下次随访日期。随访记录表的设计要点有两个一是用resident_id关联主索引二是加一个status字段标记随访状态待随访、已完成、已失访。CREATE TABLE follow_up ( id BIGINT PRIMARY KEY AUTO_INCREMENT, resident_id BIGINT NOT NULL COMMENT 关联居民主索引, follow_type VARCHAR(20) COMMENT 随访类型高血压/糖尿病/老年人, systolic INT COMMENT 收缩压, diastolic INT COMMENT 舒张压, fasting_glucose DECIMAL(5,2) COMMENT 空腹血糖, next_date DATE COMMENT 下次随访日期, status TINYINT DEFAULT 0 COMMENT 0待随访 1已完成 2失访, doctor_id BIGINT COMMENT 随访医生, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_resident (resident_id), KEY idx_next_date (next_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT随访记录;next_date加索引是为了支持“查询本周需要随访的居民”这个高频操作。status用 TINYINT 而不是字符串是因为状态值固定且查询频繁整型比较更快。这里不建物理外键用逻辑外键加索引原因是社区医疗系统经常需要批量导入历史数据物理外键会让导入变得极其麻烦而且后期分库分表时外键是累赘。这是很多教程不会告诉你的取舍。2.3 药品库存表的批次管理社区医疗平台通常还带一个简易的药品进销存。药品和普通商品最大的区别是批次和效期。同一盒阿莫西林不同批次的效期不同出库时必须按效期优先。所以库存表不能只存一个总数要按批次存。CREATE TABLE drug_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, drug_id BIGINT NOT NULL COMMENT 药品字典ID, batch_no VARCHAR(50) COMMENT 生产批号, quantity INT DEFAULT 0 COMMENT 当前批次库存, expire_date DATE COMMENT 有效期至, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_drug (drug_id), KEY idx_expire (expire_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT药品批次库存;出库时的逻辑是SELECT * FROM drug_stock WHERE drug_id? AND quantity0 ORDER BY expire_date ASC LIMIT 1先出快过期的。这个逻辑看起来简单但如果不按批次建表后期想实现效期预警和先进先出就只能推倒重来。表设计阶段多花两小时编码阶段省两天这是血泪经验。3. SpringBoot 项目骨架搭建依赖、配置与分层3.1 pom.xml 里真正需要哪些依赖网上很多 SpringBoot 教程一上来就堆几十个依赖其实社区医疗管理系统核心依赖就那么几个。下面是我一般会用的最小集合。dependencies !-- Web 层提供 REST 接口和 MVC -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MyBatis-Plus比原生 MyBatis 少写大量 XML -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency !-- MySQL 驱动 -- dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency !-- 参数校验随访表单字段多必须校验 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency !-- Lombok减少 getter/setter 噪音 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependenciesMyBatis-Plus 的版本我写的是 3.5.3.1这个版本和 SpringBoot 2.7.x 搭配稳定。如果你用的是 SpringBoot 3.x注意 MyBatis-Plus 需要换到 3.5.3.2 以上否则启动会报NoClassDefFoundError。这是“springboot版本太高”这个热搜词背后的真实痛点——版本不匹配导致的启动失败排查起来很费时间。3.2 application.yml 的关键配置项配置文件里最容易出问题的是数据库连接和 MyBatis-Plus 的映射策略。社区医疗系统的字段名通常是下划线风格如id_card而 Java 实体是驼峰idCard必须开启驼峰映射。spring: datasource: url: jdbc:mysql://localhost:3306/community_medical?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0serverTimezoneAsia/Shanghai必须加否则插入的时间会差 8 小时随访日期算错一天在医疗场景里是严重问题。logic-delete-field配置了逻辑删除居民档案和随访记录都不应该物理删除这是医疗数据的基本要求。注意逻辑删除字段deleted需要在每张表里都加上默认值 0。3.3 分层结构Controller 薄、Service 厚SpringBoot 项目最常见的分层错误是把业务逻辑写在 Controller 里。社区医疗的业务规则比如“随访日期不能早于上次随访日期”“药品出库不能超过批次库存”必须放在 Service 层Controller 只做参数接收和结果返回。RestController RequestMapping(/api/follow-up) RequiredArgsConstructor public class FollowUpController { private final FollowUpService followUpService; PostMapping public ResultLong create(RequestBody Valid FollowUpDTO dto) { return Result.ok(followUpService.createFollowUp(dto)); } GetMapping(/pending) public ResultListFollowUpVO pendingList(RequestParam String communityCode) { return Result.ok(followUpService.listPending(communityCode)); } }Controller 里没有一行业务判断Valid触发 DTO 上的校验注解Result是统一返回包装。Service 层才去检查“该居民上次随访是否已完成”“next_date 是否合理”。这种分层在项目初期看不出好处但当社区医疗的业务规则从 5 条涨到 50 条时改 Service 不会影响接口签名前端不用跟着改。这是管理系统能长期维护的关键。4. 核心业务实现随访提醒、药品出库与数据一致性4.1 随访提醒的定时任务与查询优化社区医疗平台最实用的功能之一是“待随访列表”。实现方式有两种一是每次查询时实时计算二是用定时任务预生成待办。数据量小的时候实时查询没问题但居民上万后每次打开首页都全表扫描会明显变慢。Service RequiredArgsConstructor public class FollowUpServiceImpl extends ServiceImplFollowUpMapper, FollowUp implements FollowUpService { Override public ListFollowUpVO listPending(String communityCode) { LocalDate today LocalDate.now(); LocalDate sevenDaysLater today.plusDays(7); return baseMapper.selectPendingList(communityCode, today, sevenDaysLater); } }对应的 Mapper XML 里查询条件是next_date BETWEEN #{today} AND #{sevenDaysLater} AND status 0并且resident表按community_code过滤。这里的关键是next_date上的索引必须命中否则数据量上来后查询会从毫秒级掉到秒级。我一般会在上线前用EXPLAIN确认执行计划看到typerange才放心。4.2 药品出库的并发扣减别用“查完再减”药品出库是社区医疗系统里少数有并发风险的场景。两个药房窗口同时给同一个批次出库如果代码写成“先 SELECT 查库存再 UPDATE 减库存”并发下会超卖。Transactional(rollbackFor Exception.class) public void outbound(Long drugId, int quantity) { // 按效期优先取可用批次 DrugStock stock drugStockMapper.selectAvailableBatch(drugId); if (stock null || stock.getQuantity() quantity) { throw new BizException(库存不足); } // 带条件的原子扣减quantity 出库量才更新 int affected drugStockMapper.reduceStock(stock.getId(), quantity); if (affected 0) { throw new BizException(库存扣减失败请重试); } }reduceStock的 SQL 是UPDATE drug_stock SET quantity quantity - #{quantity} WHERE id #{id} AND quantity #{quantity}。这个AND quantity #{quantity}就是防超卖的关键数据库行锁保证同一批次不会被扣成负数。Transactional保证扣减和出库记录写入在同一个事务里。这是“java怎么保证数据一致性”这个热搜词在社区医疗场景下的具体答案——不是靠分布式事务而是靠数据库行锁加条件更新。4.3 居民档案的批量导入与 XSS 过滤社区医疗系统上线时历史居民数据通常是一堆 Excel。用 Java POI 解析 Excel 导入是常见做法。但这里有个容易忽略的安全问题如果导入的姓名或地址字段里带了script标签前端渲染时可能触发 XSS。热搜词里“springboot项目全局过滤器处理上传pdf文件时xss攻击”说的就是这类问题。Component public class XssFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; // 只对写操作做参数清洗读操作放行减少开销 if (POST.equalsIgnoreCase(req.getMethod()) || PUT.equalsIgnoreCase(req.getMethod())) { chain.doFilter(new XssRequestWrapper(req), response); } else { chain.doFilter(request, response); } } }XssRequestWrapper继承HttpServletRequestWrapper在getParameter里对值做 HTML 转义。注意不要对所有请求都清洗GET 查询参数清洗会影响性能且没必要。导入的 Excel 数据在写入数据库前Service 层也要做一次转义因为过滤器只处理 HTTP 参数不处理 POI 解析出来的字符串。这两层防护缺一不可。5. 避坑与排查社区医疗系统上线后最容易翻车的五件事5.1 现象随访日期插入后差一天原因MySQL 连接串没配serverTimezone或者 Jackson 序列化时区没设。Java 的LocalDate在默认时区下转成java.sql.Date时可能偏移。解决连接串加serverTimezoneAsia/Shanghaiapplication.yml里配spring.jackson.time-zone: GMT8实体类日期字段统一用LocalDate而不是java.util.Date。5.2 现象居民列表分页查询越来越慢原因resident表数据到几万条后LIMIT偏移量大的分页会全表扫描。另外如果community_code没索引按社区筛选会走全表。解决community_code加索引分页改用“上一页最后一条 ID”的游标方式或者用 MyBatis-Plus 的分页插件配合覆盖索引。如果必须用LIMIT offset确保ORDER BY的字段有索引。5.3 现象药品库存出现负数原因出库代码用了“先查再减”的非原子操作并发下两个请求都查到库存充足然后都执行了扣减。解决改成UPDATE ... WHERE quantity ?的条件更新检查 affected rows。如果 affected 为 0 就抛异常回滚。这个改动很小但能彻底解决超卖。5.4 现象SpringBoot 启动报Failed to configure a DataSource原因pom.xml里引入了mybatis-plus-boot-starter但没配数据库连接或者 MySQL 驱动版本和数据库版本不匹配。SpringBoot 3.x 下 MySQL 驱动必须是com.mysql.cj.jdbc.Driver老版本com.mysql.jdbc.Driver已废弃。解决确认application.yml里spring.datasource配置完整SpringBoot 3.x 用mysql-connector-j而不是mysql-connector-java检查驱动类名。5.5 现象导入 Excel 后姓名显示为问号原因数据库字符集不是utf8mb4或者 JDBC 连接串没加characterEncodingutf8mb4。解决建表时显式指定DEFAULT CHARSETutf8mb4连接串加useUnicodetruecharacterEncodingutf8mb4POI 读取时确认Workbook的编码设置。生僻字在社区医疗场景很常见这个坑必须提前堵上。6. 进阶技巧用逻辑删除和操作日志把系统做成“有后悔药”的社区医疗系统的数据敏感度比普通管理系统高一个量级。居民档案删错了、随访记录改错了如果没有追溯手段就是医疗纠纷的隐患。我一般会在项目里加两个东西逻辑删除和操作日志。逻辑删除前面配置里已经提过deleted字段配合 MyBatis-Plus 的TableLogic注解删除操作自动变成UPDATE deleted1查询自动过滤。但光有逻辑删除还不够因为逻辑删除只告诉你“这条没了”不告诉你“谁在什么时候删的”。操作日志我一般用 AOP 加自定义注解实现。在 Service 方法上标OpLog(module随访, action修改)切面里拦截把操作人、操作时间、方法名、参数摘要写进operation_log表。参数摘要不要存完整 JSON只存关键字段比如随访记录的 ID 和变更前后的状态值。这样查问题时能快速定位又不会让日志表膨胀得太快。Aspect Component public class OpLogAspect { Around(annotation(opLog)) public Object around(ProceedingJoinPoint pjp, OpLog opLog) throws Throwable { Object result pjp.proceed(); // 只记录成功操作异常由全局异常处理器记录 logService.save(opLog.module(), opLog.action(), pjp.getArgs()); return result; } }这个切面要注意两点一是只记录成功返回的操作失败的操作在全局异常处理器里记避免重复二是参数摘要要做脱敏身份证号和电话不能进日志表。另外操作日志表要按月分表或者定期归档社区医疗系统跑一年下来日志量不小。还有一个实用技巧是给关键业务表加version字段做乐观锁。随访记录修改时带上版本号UPDATE ... WHERE id? AND version?如果 affected 为 0 说明有人在你之前改了提示用户刷新重试。这在多人同时操作同一个居民档案时能避免覆盖。乐观锁不是万能的但在社区医疗这种并发不高的场景里比悲观锁轻量得多。最后说一个我自己的习惯每次上线新功能前先在测试库跑一遍“删除居民 → 查随访记录 → 查操作日志”这条链路确认逻辑删除生效、日志有记录、数据能追溯。这个习惯帮我省过好几次“后悔药”。社区医疗系统的技术难度不在代码多复杂而在数据要经得起查、改错了要能还原。希望帮到你。本文还有配套的精品资源点击获取