大厂男孩的粉丝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相关依赖统一用BOM管理，避免不同模块的版本漂移。这个习惯建议所有Spring Boot项目都保留，版本集中管理能减少很多莫名其妙的依赖冲突。
2.2 数据库与ORM框架的选型
隔离人员管理系统本质上是事务型系统，数据量级在百万以内，MySQL 8.0完全够用。InnoDB引擎，事务隔离级别保持默认的REPEATABLE READ。项目里没有引入分库分表中间件，因为单表数据量不大，索引设计合理的情况下查询性能没有问题。
真正会拖慢系统的是那些没走索引的扫描和慢SQL，所以我在开发规范里定了一条：查询字段上禁止写函数，身份证号查重必须用精确匹配并配合唯一索引。这条规范看起来基础，但项目后期排查性能问题时，定位到的基本都是这类基础问题。
ORM层面选了MyBatis-Plus而不是原生MyBatis。隔离记录表有二十多个字段，如果用原生MyBatis写XML，一个insert就是一长串，维护成本高。MyBatis-Plus的单表CRUD、LambdaQueryWrapper、分页插件能省掉大量样板代码，尤其适合这类以单表操作为主的管理系统。
但必须说明，MyBatis-Plus的强项是单表操作，复杂多表聚合还是得手写SQL。比如统计在观人数、按隔离点分组汇总这类查询，我用@Select注解直接写SQL，逻辑一目了然，也方便后续调优。
2.3 前端、缓存与鉴权组件的搭配方式
前端选了Vue 3 + Element Plus，原因很简单，管理后台类项目对UI的要求集中在表格、表单、弹窗、树形菜单这些组件上，Element Plus成熟稳定，不用前端团队从零造轮子。页面用Composition API组织业务代码，Pinia存储登录态和权限信息。
Redis承担的任务比较轻量但关键：图形验证码存储、接口限流计数、以及JWT令牌的黑名单管理。JWT无状态是个优点，但代价是服务端无法主动让令牌失效。我用Redis维护一个黑名单，用户退出登录或者修改密码后，把JWT的jti加入黑名单，过期时间与令牌一致，既保留了JWT的优势，又补上了它无法主动失效的短板。
这套组合在同类项目中算是比较经典的配置，不激进但足够稳。对我来说，技术选型最重要的标准不是新，而是合适。隔离人员管理系统要的是稳定、可维护、团队上手快，Spring Boot + MyBatis-Plus + MySQL这套组合恰好满足这些要求。
3. 数据库设计：把“隔离流程”抽象成数据表与状态机
这个项目里最核心的部分是数据库设计。表结构如果设计得不好，后面写再多代码也救不回来。隔离人员管理涉及的核心实体有：人员基础信息、隔离记录、健康监测记录、解除隔离审批记录，以及用户、角色、菜单权限。
3.1 五张核心业务表的职责划分
人员基础信息表（person_info）保存人员的相对稳定属性：姓名、证件类型、证件号码、性别、联系电话、来源地、到达日期等。证件号码设置唯一约束，防止同一人重复录入。这张表只存一份基础信息，不跟隔离周期绑定。
隔离记录表（isolation_record）是状态流转的核心，每条记录代表一次完整的隔离周期。字段包括隔离编号、关联人员ID、隔离类型、入观时间、预计解除时间、实际解除时间、隔离状态、房间号、所属隔离点、负责人等。这里有个关键设计：一个人可以关联多条隔离记录，因为可能因不同情况进入多次隔离；但任意时刻只能有一条“进行中”的隔离记录，这个约束靠业务代码配合一个“当前有效记录”的标记来实现。
健康监测表（health_monitor）记录每天的监测数据，字段包括隔离记录ID、监测日期、体温、症状描述、检测结果、监测人、录入时间。用隔离记录ID和监测日期的联合唯一索引，保证同一个人同一天只能录入一次。
解除隔离审批表（release_approval）保存解除操作的时间、审批人、解除原因、备注等。我特意不直接修改隔离记录表的“实际解除时间”字段，而是通过独立审批表来关联，所有操作都有审批流水可查，审计时直接查表就行。
系统用户、角色、菜单这三张表构成RBAC权限模型。用户和角色多对多，角色和菜单多对多，后端根据登录用户的角色动态返回菜单权限和按钮权限标识。
3.2 状态机定义与流转约束
隔离记录表里的状态字段，我用枚举值来管理，一共定义了五个状态：
- PENDING_RECEIVE，待接收，人员信息已登记但还没进入隔离点；
- ISOLATING，隔离中，人员已入观，开始健康监测；
- PENDING_REVIEW，待审批解除，隔离期满，等待审批人确认；
- RELEASED，已解除，审批通过，隔离周期结束；
- TRANSFERRED，转出，人员因异常情况转出隔离点。
状态机的价值在于把非法操作挡在业务层之外。比如只有ISOLATING状态的记录才能创建健康监测，只有PENDING_REVIEW状态的记录才能执行解除审批。我在代码里单独写了一个StateMachine类来统一处理状态流转，用Map维护状态之间的合法迁移路径，非法迁移直接抛业务异常。这套设计比在工作流引擎里配流程简单得多，也方便写单元测试。
3.3 权限模型与菜单设计
权限模型用的RBAC，表结构简单，但实现时有个容易忽略的点：前端按钮的显隐只是用户体验，真正的安全控制必须放在后端接口上。我的做法是定义一个@RequirePermission注解，在Controller方法上标注权限标识，配合Spring AOP切面校验当前用户是否拥有该权限。前端根据后端返回的权限标识集合决定按钮是否渲染，后端接口独立做权限校验，双层控制互不依赖。
4. 核心功能实现：登记、监测、解除隔离全链路跑通
这一部分我按业务主链路来讲，从人员登记到健康监测，再到解除隔离和报表统计，基本覆盖了系统绝大部分的高频操作场景。
4.1 人员登记与隔离记录创建的联动
人员登记页面提交时，前端一次提交“新增人员基础信息+创建隔离记录”两个操作。后端在同一个方法里用@Transactional把这个动作包起来。业务上不能出现“人员信息入库了但隔离记录没创建成功”的中间状态，否则统计在观人数时数据就是错的。
保存逻辑里有一道核心校验：先按身份证号查重，如果存在同一证件号且关联了“进行中”的隔离记录，直接提示“该人员当前已在隔离中”。这个判断用了数据库索引和业务代码双重保证，只走精确匹配，不走模糊查询。
还有一种常见情况是历史人员再次入观。人员基础信息表里已经有记录了，前端先根据身份证号查询出历史人员信息，自动回填表单，提交时只创建新的隔离记录，不再重复插入人员基础数据。这要求开发时把“人员新增”和“隔离记录新增”拆成两个独立方法，在Service层按需组合，而不是一个方法里把所有逻辑都写完。
4.2 健康监测每日录入与异常标记
健康监测是每天使用频率最高的功能。录入员从列表页选择一条隔离中的记录，填写当天体温、症状、检测结果，提交后接口先做唯一性检查，再写入健康监测表。如果同一天已经录过，直接返回业务异常，前端弹窗提示“今日已录入，不可重复提交”。
体温超过阈值时，系统会自动给对应的隔离记录打上“重点关注”标记，这个标记是个独立字段，列表页展示时会高亮显示，方便一线人员优先关注。隔离期满前24小时，定时任务会把符合条件的记录状态从ISOLATING更新为PENDING_REVIEW，并生成待办提醒数据，审批员登录后就能在首页看到待办数量。
4.3 解除隔离审批流程
解除隔离是状态机的关键环节。审批员进入待审批列表，系统展示所有PENDING_REVIEW状态的记录，关键信息包括人员姓名、入观时间、隔离天数、健康监测摘要。
审批操作分为“同意解除”和“延期隔离”两种。同意解除会先插入一条解除审批流水，再更新隔离记录状态为RELEASED，同时写入实际解除时间。延期隔离则会让隔离记录回到ISOLATING状态，同时把预计解除时间往后推。这两个动作在一个事务里完成，保证审批流水和状态更新不会分开。
这里有个设计细节值得说：审批操作不直接改隔离记录表里的一大堆字段，而是先写审批流水表，再更新状态字段。这样做的好处是后续做审计或者看历史操作轨迹时，直接查审批表就能还原整个审批链路，不需要翻操作日志。
4.4 批量导入与导出的实现细节
隔离人员数据经常需要从Excel批量导入，因为现场拿到的往往是一张大表。这块用EasyExcel实现，按行解析，逐行做必填字段校验和身份证格式校验。校验失败的行不中断导入，而是把错误原因收集起来，导入完成后生成一份错误明细Excel供下载，录入员能直接看到第几行、哪个字段、什么问题。
导出功能相对简单，查询条件筛选后直接通过EasyExcel输出。导出大量数据时要特别注意内存问题，不要一次性把所有数据加载进内存再写文件，应该用分批查询配合流式写出。
5. 容易被忽略的坑：导入校验、权限与事务问题
5.1 EasyExcel导入时的内存与校验顺序
刚开始用POI做导入，导入两万行数据时直接把堆内存撑爆了，后来换成EasyExcel的监听器模型才解决。EasyExcel按批次解析，每批默认100条左右分批处理，内存占用非常稳定。
校验顺序也踩过坑。正确顺序是：先做行级基础校验，比如必填字段是否为空、身份证号是否合法；再做文件内去重校验，比如同一个Excel不能出现重复证件号；最后做数据库校验，比如该证件号当前是否已有进行中的隔离记录。我开始把顺序搞反了，文件内有重复数据时，前面的校验都通过了，入库时才发现重复，错误信息没法定位到具体行，录入员根本没法处理。
5.2 接口权限与按钮权限的双层控制
自定义@RequirePermission注解的权限标识，比如 person:add、isolate:release，标注在Controller方法上。AOP切面拦截请求后，从当前登录用户的权限集合里查找对应标识，不存在就抛出异常，由全局异常处理器统一返回403。
前端菜单管理里配置的每个操作按钮，也对应一个权限标识。用户登录时后端返回权限标识集合，前端用v-if控制按钮是否渲染。这里要强调的是，前端隐藏按钮只是用户体验的优化，不能作为安全手段。真正的底线是后端每个接口都必须做权限校验，否则绕过前端直接调API一样能操作。
5.3 JWT令牌续期与主动失效
JWT的access token有效期设置2小时，refresh token设置7天。access token过期后，前端用refresh token调刷新接口换新的accesstoken。refresh token也存一份到Redis，关联用户ID，刷新时先校验Redis里的记录是否存在且在有效期内。
令牌主动失效的需求出现在修改密码场景：用户改完密码后，所有已登录设备需要全部下线。纯JWT做不到这一点，所以用Redis黑名单方案。修改密码时把当前用户的所有refresh token加入黑名单，下次刷新时发现refresh token不在合法列表里，直接返回登录已失效，前端跳转登录页。
5.4 Spring Boot事务失效的几个注意点
项目里出现过几次事务不生效的“灵异事件”，排查后都是经典原因。一是方法被同一个类内部调用，AOP代理没走到，事务注解形同虚设；二是在方法内部直接try-catch吞掉异常，事务管理器以为方法正常返回，全部回滚没有生效；三是事务方法被final修饰，CGLIB代理无法生成子类覆盖。
解决办法不复杂：自调用问题把方法抽到另一个Service类里，或者注入自身代理；try-catch问题要在catch块里重新抛出异常，并在注解上指定rollbackFor = Exception.class；final方法去掉final修饰。这类问题最好通过代码规约工具在开发阶段就拦截，不要等线上出问题再排查。
6. 上线运行之后的几点真实体会
6.1 业务侧的体验优化比技术炫技更关键
系统上线后收到的大量反馈不是关于某个功能没实现，而是操作体验不够顺手。录入页面的默认值能不能自动带出来，下拉框能不能搜索，之前录入过的历史人员信息能不能一键回填，这些看似琐碎的细节，直接决定了录入员每天的工作效率。
我意识到，对这种管理系统来说，技术架构是地基，但用户真正感受到的是每天的交互细节。设计阶段就应该多问业务方：一天要录多少条数据，录一条最快要操作几次，哪些字段可以默认，哪些选项可以复用。这些需求访谈做扎实了，比什么都重要。
6.2 两个让我印象最深的运维教训
第一个是配置校验。Spring Boot项目的application.yml里关键配置如果漏配或配错，最好在启动时就快速失败，而不是等运行到某个接口才报错。我在项目里写了一个配置校验类，用@ConfigurationProperties绑定配置后，在启动阶段做必填项判断，有问题直接抛异常终止启动。这个习惯在多环境部署时帮我省了很多麻烦。
第二个是接口统一返回结构。前后端联调时最怕的就是接口返回格式不统一，一会儿是对象，一会儿是数组，一会儿又包了一层状态码。项目里定义了统一的Result
回看整个项目，隔离人员管理系统的技术难度不算高，真正的复杂度在业务状态的严谨性和数据链路的完整性上。Spring Boot提供了一套成熟可靠的底座，让我能把更多精力放在业务逻辑本身。这个项目给我的最大收获不是某个炫技的功能，而是认识到：在管理系统这一类项目里，稳定、一致、好用，永远比花哨的技术方案更有价值。