大厂男孩的粉丝1. 从业务现场说起：隔离人员管理系统最麻烦的不是增删改查
做这个项目之前，我一直觉得隔离人员管理系统也就是“字段多一些的增删改查”，真正动手之后才意识到，这个系统的难点从来不在CRUD本身，而在于状态流转的一致性和数据台账的实时性。
先交代一下背景。这是一套面向基层管理场景的隔离人员管理系统，核心对象是隔离人员，业务覆盖人员接收登记、健康监测记录、隔离状态跟踪、解除隔离审批，以及各类统计报表。系统上线之前，这些工作主要靠Excel表格和微信群协作，每天人员信息靠人工统计，隔离状态靠口口相传，数据不一致的情况非常突出。比如同一个隔离人员，隔离点登记表上写着“已解除”，日报表里却还统计在“在观人数”里，这类问题几乎每天都会出现。
项目第一版定下的技术方向是Spring Boot 2.7.18 + MyBatis-Plus + MySQL 8.0，鉴权用JWT，缓存用Redis，前端选Vue 3 + Element Plus，整体采用前后端分离架构，后端打包成单体jar部署在一台4核8G的服务器上。整个项目的功能模块看起来不复杂，但真正梳理的时候发现，要处理的业务规则并不少。
我后来把这个系统的需求抽象成了三个核心痛点。
第一，人员状态的一致性。隔离人员从“待接收”到“隔离中”再到“已解除”，中间还有“待审批解除”“转出”等状态。如果状态散落在Excel里，两个人维护两张表，数据永远对不齐。用数据库表加状态机来管理，才能保证同一个证件号在任何时刻只对应一条有效的隔离记录。
第二，健康监测数据的留痕。每天的体温、症状、抗原检测结果都要按天记录，必须有经办人、有录入时间，不能事后补录，更不能一天录两次。这个需求逼着我在表设计上加唯一索引，在接口层加事务，双重保证数据不被污染。
第三，统计报表的时效性。基层每天要在固定节点上报各类统计口径，比如今日新增多少、在观多少、解除多少、异常多少。靠人工数数不现实，所有统计逻辑必须后端统一计算，前端调一个接口拿到所有数字。
这套系统的业务逻辑不算复杂，但它直接关系到公共卫生管理场景下的实际调度，数据错了影响面很大。所以我在设计上宁可多写防御性代码，把边界情况处理干净，也不愿意后期运维时被数据问题反复折磨。这份谨慎，在后来的开发和上线阶段帮了不少忙。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型复盘：Spring Boot在这个场景里到底胜在哪
动手写代码之前，我在技术选型上花了大概一周时间。最后核心框架定了Spring Boot，现在回看这个决策，有几个关键取舍值得展开细说。
2.1 Spring Boot版本：为什么锁定2.7.18而不是追新
开发时Spring Boot 3.x已经推出了一段时间，网上关于Spring Boot版本太高的讨论也不少。我最后选了2.7.18，核心原因是生态兼容性。2.7.x是2.x系列的收尾维护版本，仍然使用javax命名空间，和大量国内中间件、老版本的MyBatis-Plus、自定义工具类配合起来不会出命名空间冲突。
这个项目部署环境是JDK 8，Spring Boot 2.7.18本身对JDK 8的支持非常稳定。Spring Boot 3.x强制要求JDK 17以上，同时把javax替换成了jakarta，如果团队里没有非用不可的新特性需求，为了升级而升级，反而会在迁移过程中踩一堆没有价值的坑。
我在项目里把Spring Boot相关依赖