尧图网页设计 
简介面向养老服务信息化场景基于 Java 开发的中州养老系统源码定位于老年人项目综合管理平台涵盖信息管理、服务预约、健康监测等核心业务适合需要完成养老平台设计或 Java Web 项目实战的开发者参考。压缩包共 115 个文件约 351KB以 98 个 Java 源文件为主体用于实现界面、业务逻辑与数据处理13 个 XML 配置负责数据库与通信参数另含 YML、JSON 及 Git 忽略文件便于配置管理和版本协作。项目按 common、web、service 分层组织common 提供通用工具类web 处理用户请求与页面交互service 聚焦养老业务逻辑模块边界清晰具备较好的学习与二次开发价值。目前在 CSDN 已有 347 人学习浏览可用于毕业设计、课程项目或养老信息化方案的快速搭建与功能拆解。1. 中州养老系统这套 Java 源码解决的是养老院运营里的哪三件事做养老机构信息化的人应该都有同感养老院的管理系统跟普通的进销存、OA 完全是两码事。它真正的复杂度不在前台接待而在护理排班、费用结算和健康档案这三块——护工谁上白班谁上夜班老人入住时交了多少押金、每个月床位费和护理费按什么标准算退住时剩余费用怎么退这些逻辑稍有偏差就会引发家属投诉。中州养老系统就是围绕这三件事设计的一套 Java 后端源码业务上覆盖了老人档案、床位入住、护理任务、费用账单和探视预约等典型场景技术上走的是 Spring Boot 加 MyBatis-Plus 这套国内 Java 开发最主流、最容易二次开发的路线。对想快速落地一套养老院管理系统、或者正在做 Java 课程设计和毕业设计的人这套源码的价值在于你能直接看到养老业务表结构怎么建、结算代码怎么写、权限怎么配省掉从头调研业务的时间。2. 拆解中州养老系统的业务边界与技术选型先定清楚模块再谈框架2.1 养老系统跟普通管理系统的业务边界差在哪很多第一次接触养老系统的开发者会下意识地按“人员管理 收费”来设计但真正去过养老院现场就会发现业务远不止这两块。我把中州养老系统的业务域拆成五个部分基本上也是这类系统通用的划分方式第一是老人档案与入住管理。老人入院要登记身份证信息、家属联系人、既往病史和药物过敏史同时分配床位、确定护理等级。档案里还要记录入住日期和退住日期因为后面所有费用结算都要按入住区间去算天数。第二是床位管理。养老院的床位不是简单的编号它有区域、楼层、房间、床号有“空床”“已入住”“维修中”的状态还会涉及调床操作——老人从三人间换到单人间费用标准就得跟着变。第三是护理排班与任务执行。这是养老系统区别于普通管理系统最明显的地方。护理员分白班、夜班、轮班每个班次要照护哪些老人、要做哪些事测血压、喂药、翻身、打扫都要排到具体人和具体时间执行后还要回填记录。第四是费用结算。包括入住时的一次性押金、每个月的床位费、护理费、伙食费以及退住时的按天折算和押金退还。这一块最考验代码功底金额不能出现一分钱误差。第五是探视预约与访客登记。疫情之后这套流程被很多养老院提到了很高的优先级家属来探视要在系统里预约时段到院后登记系统会记录探视人与老人的关系。把这五块理清楚后再去看源码结构就不会觉得目录乱。常见做法是按业务域分包elder、bed、care、charge、visit控制器只管接收参数和返回结果业务逻辑全部放 service数据访问统一走 mapper。如果源码里 controller 写得太厚、service 里全是 SQL那后续扩展排班规则和计费规则时一定会返工。2.2 Java 技术栈选型为什么是 Spring Boot MyBatis-Plus 而不是别的中州养老系统既然标注是 Java 开发技术栈基本就能猜到但选型理由值得说清楚。Spring Boot 负责把 HTTP 接口、JSON 序列化、数据源连接这些基础设施自动装配好开发者只需要写业务代码MyBatis-Plus 则解决单表 CRUD 的重复劳动内置的分页插件、代码生成器和条件构造器能省下大量样板代码。这套组合是当前 Java 后端就业市场里遇到频率最高的阵容也是二次开发成本最低的方案。一个常见问题是为什么不用 Spring Data JPA我的经验是养老系统的查询场景大多是“多条件动态筛选”比如查“某区域、护理等级为二级、本月尚未生成账单的老人”MyBatis-Plus 的 LambdaQueryWrapper 可以链式拼条件比 JPA 的 Specification 更直观而且费用、报表这类复杂聚合查询最终多半要写自定义 SQLMyBatis 的 XML 方式比 JPA 的 Query 更好维护。持久层之外缓存一般选 Redis用来存登录会话、验证码和热点数据鉴权可以用 Sa-Token 这类轻量框架也可以直接用 Spring Security。我一般建议中小型项目选 Sa-Token因为它开箱即用注解一个 SaCheckRole 就能控制接口权限对养老院内部系统这种角色固定的场景更合适Spring Security 配置门槛相对高团队不熟就容易踩配置坑。前端部分如果源码自带页面通常是一套 Vue 管理后台或者 Thymeleaf 服务端页面如果只有后端接口也没关系后面接任何前端都行重点在于接口返回体要统一。中州养老系统这类源码的价值主要在于后端的业务逻辑和技术套路前端界面开发相对标准化按接口文档重写一套反而更快。3. 养老系统数据库怎么建核心表结构、字段设计与关键 SQL3.1 核心表应该怎么拆从业务对象到表关系我拿到养老系统源码惯例是先看数据库脚本因为建表最能反映作者对业务的理解。中州养老系统里至少要包含这几张核心表老人档案表、床位表、护理等级表、排班表、护理任务执行表、费用账单表和缴费记录表。表之间的关系是老人表关联床位表和护理等级表护理等级表再关联护理费单价排班表关联护理员和老人每天生成一批护理任务账单表按月份关联老人缴费记录表关联账单形成一对多的流水关系。这里有一个关键点老人基本信息、床位和护理等级不要直接堆在同一张表里因为老人可能调床、调护理等级如果不分开历史数据会被覆盖后面查“上个月的护理费按什么标准算的”就彻底说不清了。常见做法是老人表存当前状态另外建表或直接在档案表里保留当前等级但所有在职和退住老人的费用明细都要在账单里留存快照。另外需要特别注意一张“护理费用标准表”字段至少要覆盖等级编码、等级名称、月费用金额、生效日期和失效日期。家属对费用有疑问时系统要能回答出“这位老人在这个月是按哪个单价算出来的”单价标准一旦调整必须有生效区间来切分。3.2 直接用 SQL 建这几张表字段注解与设计意图下面这段 SQL 是单条独立可执行的直接按顺序建表即可适用于中州养老系统里最核心的“老人档案 护理计划 费用账单”三张表-- 老人档案表一个人一条记录状态区分在住和退住 CREATE TABLE elder_info ( id BIGINT NOT NULL COMMENT 主键ID, elder_no VARCHAR(32) NOT NULL COMMENT 老人编号用于线下单据对应, name VARCHAR(64) NOT NULL COMMENT 姓名, id_card VARCHAR(18) NOT NULL COMMENT 身份证号, gender TINYINT NOT NULL COMMENT 性别1男 2女, bed_id BIGINT DEFAULT NULL COMMENT 当前床位ID调床后更新, care_level VARCHAR(16) NOT NULL COMMENT 护理等级编码关联护理标准表, checkin_date DATE NOT NULL COMMENT 入住日期, checkout_date DATE DEFAULT NULL COMMENT 退住日期空表示在住, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1在住 2已退住, PRIMARY KEY (id), UNIQUE KEY uk_elder_no (elder_no), KEY idx_bed_id (bed_id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 老人档案表;老人表是一切业务的主线所有费用和任务都挂在这个表的主键上。这里 bed_id 用了可空字段因为老人可能在入住前或调床间隙没有床位身份证号建议做唯一索引但实际业务里会存在少数证件类型不是身份证的情况所以没有直接加唯一约束。老人编号是线下文件柜里也要用的编号必须唯一否则单据对不上。-- 护理计划表根据护理等级生成模板化的每日任务 CREATE TABLE care_plan ( id BIGINT NOT NULL COMMENT 主键ID, elder_id BIGINT NOT NULL COMMENT 老人ID, level_code VARCHAR(16) NOT NULL COMMENT 护理等级编码, task_name VARCHAR(64) NOT NULL COMMENT 任务名称如晨间测血压, task_type TINYINT NOT NULL COMMENT 任务类型1生命体征 2药物 3生活照料, start_time TIME NOT NULL COMMENT 计划执行时间, repeat_type TINYINT NOT NULL DEFAULT 1 COMMENT 重复类型1每天 2每周, PRIMARY KEY (id), KEY idx_elder_id (elder_id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 护理计划表;护理计划是排班系统的基础数据。真正落执行记录时系统会每天根据老人当前有效的护理计划生成一批护理任务。需要注意的一点是任务名称、执行时间这类信息不要直接写死在排班表里因为调整护理等级后计划要整体变化拆成计划表和任务表两层改计划就能带动后续所有排班。-- 费用账单表按月生成金额用 decimal绝不用 double CREATE TABLE charge_bill ( id BIGINT NOT NULL COMMENT 主键ID, elder_id BIGINT NOT NULL COMMENT 老人ID, bill_month CHAR(7) NOT NULL COMMENT 账单月份如2024-08, bed_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 床位费, care_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 护理费, meal_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 伙食费, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 应收总额, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0未结 1已结 2已作废, generate_time DATETIME NOT NULL COMMENT 生成时间, PRIMARY KEY (id), KEY idx_elder_month (elder_id, bill_month) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 月度费用账单表;账单表的关键设计是bill_month与elder_id的唯一联合索引防止同一个月给老人重复生成账单。金额字段一律用DECIMAL(10,2)这个没有例外。之前见过用double存金额的项目累计多次运算后误差最多能差出好几毛养老院财务对不上就要从每天几十笔流水里重新核属于血泪教训。账单单据里还应该再加一个快照字段像care_level_snapshot这样的字段存生成账单当时的护理等级名称和单价这样后续调价不影响历史单据的追溯。3.3 设计表结构时容易忽略的三个索引细节第一所有外键关联字段都必须加索引。之前排查过一个养老系统接口慢的问题老人在住列表查询语句跑了将近三秒执行计划里全是全表扫描就是因为charge_bill表上elder_id没加索引。MySQL 不会自动为外键创建索引还得在建表时显式加。第二在住老人的列表页要按checkin_date排序所以checkin_date字段最好和status建联合索引两列顺序是 status 在前、checkin_date 在后。对在住老人列表的筛选来说这个索引能让查询直接走索引覆盖。第三退住时间字段会经常用来做区间统计例如退住人数月度趋势此时需要考虑按checkout_date建索引。大多数护理系统只统计在住人数却忽略退住分析所以中州养老系统的报表模块如果做了这一项说明业务设计比较周全。4. 用 Java 实现养老费用结算与护理排班核心代码、参数与调整方法4.1 月度费用结算的按天折算金额计算必须用 BigDecimal在养老业务里费用结算是单点最容易出 bug 的地方因为“整月费用”和“不足一个月”的折算规则并不是简单用总费用除以 30。老人在月中入住或退住床位费怎么算、伙食费怎么算、护理费又怎么算一旦规则不一致就会引来家属投诉。我一般会先把规则直接写进代码注释里方便后续接手的人核对。业务流程是先取出老人的入住日期、退住日期可空、床位费和护理费单价再按自然月做日费用折算。public BigDecimal calcMonthlyFee(LocalDate checkinDate, BigDecimal monthlyFee, LocalDate billStart, LocalDate billEnd) { // 账单区间为某月自然日如 2024-08-01 至 2024-08-31 LocalDate effectiveStart checkinDate.isAfter(billStart) ? checkinDate : billStart; LocalDate effectiveEnd (billEnd null) ? billEnd : billEnd; // 在住则以账单月底为截止 int daysInMonth billStart.lengthOfMonth(); // 不足整月按实际天数折算整月则直接用月费 if (effectiveStart.equals(billStart)) { return monthlyFee; } long days ChronoUnit.DAYS.between(effectiveStart, billEnd.plusDays(1)); BigDecimal dailyFee monthlyFee.divide(BigDecimal.valueOf(daysInMonth), 4, RoundingMode.HALF_UP); return dailyFee.multiply(BigDecimal.valueOf(days)).setScale(2, RoundingMode.HALF_UP); }这段逻辑里有一个取值动作值得单独说明monthlyFee.divide(..., 4, RoundingMode.HALF_UP)先保留四位小数然后乘实际天数最后再保留两位。先除后乘的顺序能减少累计误差如果哪一步直接写成两位小数多个账单叠加起来误差就可能变大。另外在住老人账单结束时终点取的是billEnd也就是当月的最后一天如果老人在月中退住那么在退住结算时会单独生成一张“退住结算单”把入住期间的未结费用连同押金退还一起做掉。费用结算的保存动作我把整套逻辑放进 service 层关键是用事务把“生成账单”和“更新老人状态”绑在一起。比如退住结算就需要在checkout方法上标注 Transactional 注解将退住时间回写、生成结算账单、更新床位状态三个操作放在同一个事务里任何一个失败都会整体回滚避免出现老人已退住但床位还占着的状态。4.2 护理排班怎么排轮转算法与任务批量生成护理排班的实现我见过两种做法简单方案是排班表里直接存“某护理员在某天负责哪些老人”每次手动指派更通用、也更省人力的方案是“模板轮转每日生成”。中州养老系统做的是后者。具体思路是护理员分为若干组每组对应一种班次轮转序列比如白班、夜班、休息、白班……系统按日期算出每个组当天应该执行哪个班次然后批量生成护理任务。public void generateDailyTasks(LocalDate day) { // 查出当天所有在住且护理计划为启用状态的老人 ListElderInfo elders elderMapper.selectList( new LambdaQueryWrapperElderInfo() .eq(ElderInfo::getStatus, 1) .eq(ElderInfo::getPlanEnabled, 1)); ListCareTask tasks new ArrayList(); for (ElderInfo elder : elders) { // 依据老人的护理等级获取计划任务模板 ListCarePlan plans carePlanMapper.selectList( new LambdaQueryWrapperCarePlan() .eq(CarePlan::getElderId, elder.getId())); for (CarePlan plan : plans) { CareTask task new CareTask(); task.setElderId(elder.getId()); task.setTaskName(plan.getTaskName()); task.setPlanTime(plan.getStartTime()); task.setPlanDate(day); task.setStatus(0); // 0 待执行 tasks.add(task); } } // 批量插入注意控制单批规模 if (!tasks.isEmpty()) { careTaskMapper.insertBatchSomeColumn(tasks); } }批量插入这里用了 MyBatis-Plus 的insertBatchSomeColumn方法它能把列表一次性插入数据库比循环单条插入效率高出很多。需要留心的是大批量插入时一次插入的条目数建议控制在 500 条以内通常可以先按每 200 条一批处理避免数据库单条 SQL 执行时间过长。有些 MyBatis-Plus 版本里insertBatchSomeColumn并不是内置的公共方法需要自己注一个自定义 SQL 注入器这块配套源码中一般已经做好了。排班执行后的回填也有一个坑任务完成时间、执行人、结果备注都要记录但不要直接去“更新”原本的任务记录而是要保留每次执行的历史。原因很简单护理员测完血压后可能复测要给家属看的是完整记录而不是覆盖前一条。4.3 护理等级调整时的联动更新中州养老系统有一个很容易被忽略的细节老人护理等级调整后不只是改一个字段已生成的当月护理计划和费用都要联动变化。月度账单还没有生成时调整等级直接改老人当前等级就行但如果当月账单已经生成就需要走“账单作废再重算”的流程作废后生成一张新的账单。这个场景在系统里通常体现为账单状态字段的流转未结、已结、已作废。调整等级的操作建议收敛在单独的服务方法里不要允许直接通过更新接口改等级字段否则月结时数据一定会乱。方法里先更新老人表再作废未结清的当月账单最后按新单价重算。这三步同样要放在同一事务内保证任何一步失败都不留半个状态。5. 中州养老系统避坑指南分页失效、金额精度、时间格式与权限漏配5.1 分页只返回了全部数据忘记注册 MyBatis-Plus 分页插件现象是列表页调用分页接口后返回的总记录数正确但每页总是把所有数据都查出来前端翻页无效。这个坑在我接手过的几个 Java 项目里都出现过最根本的原因是 MyBatis-Plus 的分页功能依赖一个内置拦截器没有配置它Page参数会被当成普通参数传进 SQL自然分不了页。解决方法是新建一个 MybatisPlusConfig 配置类把 PaginationInnerInterceptor 注册为 MyBatis-Plus 的插件Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这个配置类放在 config 包下启动时 Spring 会自动装配。业务代码里执行分页查询时要保证查询语句没有以自定义 SQL 的方式绕过拦截器。我一般建议在分页查询方法里直接打印 SQL 日志确认带有LIMIT关键字不要靠肉眼判断。5.2 账单金额出现 0.000000004 这种精度问题金额滥用 double现象是账单表中存了类似123.45000000000002的值前端展示时四舍五入看不出问题但一旦做多笔账单合计就出现一分钱误差。原因是 Java 里用double计算金额二进制浮点数无法精确表示十进制小数。解决方案是从源头杜绝 double数据库用DECIMAL(10,2)Java 实体类用BigDecimal所有运算一律走 BigDecimal禁止在代码里让 MySQL 做浮点乘法再返回给 Java 接收。如果数据库里已经有脏数据就需要写一次性脚本修正同时把代码里所有金额运算统一替换掉。5.3 时间返回给前端变成一串数字LocalDateTime 序列化问题现象是前端拿到2024-08-15T10:23:45或一串数字时间戳展示在页面上很不友好。原因是实体类用了 Java 8 的LocalDateTime但项目没配 Jackson 的 JavaTimeModule或者全局日期格式配置缺失。常见做法是在 application.yml 里统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这个配置只对java.util.Date类生效因此还需要单独引入 jackson-datatype-jsr310 依赖并加一个全局配置类来注册 JavaTimeModule。此外对于某些需要单独控制格式的字段比如账单的“生成时间”可以直接在实体类字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)。中州养老系统的源码如果同时存在这两种配置说明作者实际遇到过这个坑属于常规处理。5.4 护理员能查不在自己名下老人档案权限只控制了菜单没控制数据行现象是登录护理员账号后调用老人详情接口能查到任何老人的敏感健康信息。原因多半是后端接口没有做数据权限过滤仅靠前端菜单隐藏不能防止直接构造请求访问。解决思路是在查询层加一层行级权限拦截简单做法是在 Service 里判断当前登录用户的角色管理员可查全部护理员查自己负责的老人列表家属端口只查与本账号关联的老人。推荐在接口实现时统一走一个DataScope工具类内部先组装条件再传给 Mapper避免每个接口都手写权限判断造成遗漏。5.5 碰到“数据库字段下划线配不上实体类驼峰”导致查询列全部为 NULL现象是明明表里有数据但实体类字段全是 null这种问题常见于手工写的resultMap漏配了字段映射。MyBatis-Plus 默认开启驼峰转换但自定义 SQL 使用resultType时并不涉及 resultMap 映射逻辑应该没问题。真正会踩坑的是在 XML 里自定义结果集时没有加autoMappingtrue或者字段用别名AS careLevel又和驼峰策略冲突直接把查询结果列改成下划线别名并检查配置项map-underscore-to-camel-case: true就能解决。6. 从拿到源码到上线验证一个能帮你少走两个月弯路的做法源码拿回来后建议先别急着改功能先做一遍“接口自测 数据巡检”再动手。第一步是启动项目配置好数据源用 Swagger 或 Knife4j 把所有接口过一遍重点看三件事登录鉴权是否拦截了未携带 token 的请求、分页接口是否真的分页、老人列表与账单查询的时间字段格式是否正常。第二步是往数据库插入几组边界数据比如当月 1 日入住、当月 31 日退住、跨月退住和护理等级月中调整逐个跑费用结算接口核对金额是否正确。养老业务里这类边界数据最容易暴露折算逻辑 bug比写几百行测试代码都管用。第三步是验证排班生成逻辑把系统时间拨到下个月 1 号手动触发一次每日任务生成判断是否覆盖了跨月场景。做完验证再动手改业务也不迟。如果这套源码会用于生产环境部署时建议把 MySQL 换成 8.0 以上版本、加上 Redis 做会话缓存并且把默认的管理员初始密码改掉。后续做二次开发时常见的做法是在调度层加一个定时任务每天凌晨生成当日的护理任务这一步对源码的改动不大但对实际落地效果提升非常明显。这也是我每次接手养老系统源码后第一个做的改造从手动生成改成定时任务后管理员每天早上不用再点一次按钮使用体验完全是两回事。希望这套流程能帮你从拿到源码到稳定运行的路上少踩几个坑真正把精力花在业务功能迭代上。本文还有配套的精品资源点击获取 基于Spring Boot与MyBatis-Plus的养老院管理系统源码解析
简介面向养老服务信息化场景基于 Java 开发的中州养老系统源码定位于老年人项目综合管理平台涵盖信息管理、服务预约、健康监测等核心业务适合需要完成养老平台设计或 Java Web 项目实战的开发者参考。压缩包共 115 个文件约 351KB以 98 个 Java 源文件为主体用于实现界面、业务逻辑与数据处理13 个 XML 配置负责数据库与通信参数另含 YML、JSON 及 Git 忽略文件便于配置管理和版本协作。项目按 common、web、service 分层组织common 提供通用工具类web 处理用户请求与页面交互service 聚焦养老业务逻辑模块边界清晰具备较好的学习与二次开发价值。目前在 CSDN 已有 347 人学习浏览可用于毕业设计、课程项目或养老信息化方案的快速搭建与功能拆解。1. 中州养老系统这套 Java 源码解决的是养老院运营里的哪三件事做养老机构信息化的人应该都有同感养老院的管理系统跟普通的进销存、OA 完全是两码事。它真正的复杂度不在前台接待而在护理排班、费用结算和健康档案这三块——护工谁上白班谁上夜班老人入住时交了多少押金、每个月床位费和护理费按什么标准算退住时剩余费用怎么退这些逻辑稍有偏差就会引发家属投诉。中州养老系统就是围绕这三件事设计的一套 Java 后端源码业务上覆盖了老人档案、床位入住、护理任务、费用账单和探视预约等典型场景技术上走的是 Spring Boot 加 MyBatis-Plus 这套国内 Java 开发最主流、最容易二次开发的路线。对想快速落地一套养老院管理系统、或者正在做 Java 课程设计和毕业设计的人这套源码的价值在于你能直接看到养老业务表结构怎么建、结算代码怎么写、权限怎么配省掉从头调研业务的时间。2. 拆解中州养老系统的业务边界与技术选型先定清楚模块再谈框架2.1 养老系统跟普通管理系统的业务边界差在哪很多第一次接触养老系统的开发者会下意识地按“人员管理 收费”来设计但真正去过养老院现场就会发现业务远不止这两块。我把中州养老系统的业务域拆成五个部分基本上也是这类系统通用的划分方式第一是老人档案与入住管理。老人入院要登记身份证信息、家属联系人、既往病史和药物过敏史同时分配床位、确定护理等级。档案里还要记录入住日期和退住日期因为后面所有费用结算都要按入住区间去算天数。第二是床位管理。养老院的床位不是简单的编号它有区域、楼层、房间、床号有“空床”“已入住”“维修中”的状态还会涉及调床操作——老人从三人间换到单人间费用标准就得跟着变。第三是护理排班与任务执行。这是养老系统区别于普通管理系统最明显的地方。护理员分白班、夜班、轮班每个班次要照护哪些老人、要做哪些事测血压、喂药、翻身、打扫都要排到具体人和具体时间执行后还要回填记录。第四是费用结算。包括入住时的一次性押金、每个月的床位费、护理费、伙食费以及退住时的按天折算和押金退还。这一块最考验代码功底金额不能出现一分钱误差。第五是探视预约与访客登记。疫情之后这套流程被很多养老院提到了很高的优先级家属来探视要在系统里预约时段到院后登记系统会记录探视人与老人的关系。把这五块理清楚后再去看源码结构就不会觉得目录乱。常见做法是按业务域分包elder、bed、care、charge、visit控制器只管接收参数和返回结果业务逻辑全部放 service数据访问统一走 mapper。如果源码里 controller 写得太厚、service 里全是 SQL那后续扩展排班规则和计费规则时一定会返工。2.2 Java 技术栈选型为什么是 Spring Boot MyBatis-Plus 而不是别的中州养老系统既然标注是 Java 开发技术栈基本就能猜到但选型理由值得说清楚。Spring Boot 负责把 HTTP 接口、JSON 序列化、数据源连接这些基础设施自动装配好开发者只需要写业务代码MyBatis-Plus 则解决单表 CRUD 的重复劳动内置的分页插件、代码生成器和条件构造器能省下大量样板代码。这套组合是当前 Java 后端就业市场里遇到频率最高的阵容也是二次开发成本最低的方案。一个常见问题是为什么不用 Spring Data JPA我的经验是养老系统的查询场景大多是“多条件动态筛选”比如查“某区域、护理等级为二级、本月尚未生成账单的老人”MyBatis-Plus 的 LambdaQueryWrapper 可以链式拼条件比 JPA 的 Specification 更直观而且费用、报表这类复杂聚合查询最终多半要写自定义 SQLMyBatis 的 XML 方式比 JPA 的 Query 更好维护。持久层之外缓存一般选 Redis用来存登录会话、验证码和热点数据鉴权可以用 Sa-Token 这类轻量框架也可以直接用 Spring Security。我一般建议中小型项目选 Sa-Token因为它开箱即用注解一个 SaCheckRole 就能控制接口权限对养老院内部系统这种角色固定的场景更合适Spring Security 配置门槛相对高团队不熟就容易踩配置坑。前端部分如果源码自带页面通常是一套 Vue 管理后台或者 Thymeleaf 服务端页面如果只有后端接口也没关系后面接任何前端都行重点在于接口返回体要统一。中州养老系统这类源码的价值主要在于后端的业务逻辑和技术套路前端界面开发相对标准化按接口文档重写一套反而更快。3. 养老系统数据库怎么建核心表结构、字段设计与关键 SQL3.1 核心表应该怎么拆从业务对象到表关系我拿到养老系统源码惯例是先看数据库脚本因为建表最能反映作者对业务的理解。中州养老系统里至少要包含这几张核心表老人档案表、床位表、护理等级表、排班表、护理任务执行表、费用账单表和缴费记录表。表之间的关系是老人表关联床位表和护理等级表护理等级表再关联护理费单价排班表关联护理员和老人每天生成一批护理任务账单表按月份关联老人缴费记录表关联账单形成一对多的流水关系。这里有一个关键点老人基本信息、床位和护理等级不要直接堆在同一张表里因为老人可能调床、调护理等级如果不分开历史数据会被覆盖后面查“上个月的护理费按什么标准算的”就彻底说不清了。常见做法是老人表存当前状态另外建表或直接在档案表里保留当前等级但所有在职和退住老人的费用明细都要在账单里留存快照。另外需要特别注意一张“护理费用标准表”字段至少要覆盖等级编码、等级名称、月费用金额、生效日期和失效日期。家属对费用有疑问时系统要能回答出“这位老人在这个月是按哪个单价算出来的”单价标准一旦调整必须有生效区间来切分。3.2 直接用 SQL 建这几张表字段注解与设计意图下面这段 SQL 是单条独立可执行的直接按顺序建表即可适用于中州养老系统里最核心的“老人档案 护理计划 费用账单”三张表-- 老人档案表一个人一条记录状态区分在住和退住 CREATE TABLE elder_info ( id BIGINT NOT NULL COMMENT 主键ID, elder_no VARCHAR(32) NOT NULL COMMENT 老人编号用于线下单据对应, name VARCHAR(64) NOT NULL COMMENT 姓名, id_card VARCHAR(18) NOT NULL COMMENT 身份证号, gender TINYINT NOT NULL COMMENT 性别1男 2女, bed_id BIGINT DEFAULT NULL COMMENT 当前床位ID调床后更新, care_level VARCHAR(16) NOT NULL COMMENT 护理等级编码关联护理标准表, checkin_date DATE NOT NULL COMMENT 入住日期, checkout_date DATE DEFAULT NULL COMMENT 退住日期空表示在住, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1在住 2已退住, PRIMARY KEY (id), UNIQUE KEY uk_elder_no (elder_no), KEY idx_bed_id (bed_id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 老人档案表;老人表是一切业务的主线所有费用和任务都挂在这个表的主键上。这里 bed_id 用了可空字段因为老人可能在入住前或调床间隙没有床位身份证号建议做唯一索引但实际业务里会存在少数证件类型不是身份证的情况所以没有直接加唯一约束。老人编号是线下文件柜里也要用的编号必须唯一否则单据对不上。-- 护理计划表根据护理等级生成模板化的每日任务 CREATE TABLE care_plan ( id BIGINT NOT NULL COMMENT 主键ID, elder_id BIGINT NOT NULL COMMENT 老人ID, level_code VARCHAR(16) NOT NULL COMMENT 护理等级编码, task_name VARCHAR(64) NOT NULL COMMENT 任务名称如晨间测血压, task_type TINYINT NOT NULL COMMENT 任务类型1生命体征 2药物 3生活照料, start_time TIME NOT NULL COMMENT 计划执行时间, repeat_type TINYINT NOT NULL DEFAULT 1 COMMENT 重复类型1每天 2每周, PRIMARY KEY (id), KEY idx_elder_id (elder_id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 护理计划表;护理计划是排班系统的基础数据。真正落执行记录时系统会每天根据老人当前有效的护理计划生成一批护理任务。需要注意的一点是任务名称、执行时间这类信息不要直接写死在排班表里因为调整护理等级后计划要整体变化拆成计划表和任务表两层改计划就能带动后续所有排班。-- 费用账单表按月生成金额用 decimal绝不用 double CREATE TABLE charge_bill ( id BIGINT NOT NULL COMMENT 主键ID, elder_id BIGINT NOT NULL COMMENT 老人ID, bill_month CHAR(7) NOT NULL COMMENT 账单月份如2024-08, bed_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 床位费, care_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 护理费, meal_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 伙食费, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 应收总额, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0未结 1已结 2已作废, generate_time DATETIME NOT NULL COMMENT 生成时间, PRIMARY KEY (id), KEY idx_elder_month (elder_id, bill_month) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 月度费用账单表;账单表的关键设计是bill_month与elder_id的唯一联合索引防止同一个月给老人重复生成账单。金额字段一律用DECIMAL(10,2)这个没有例外。之前见过用double存金额的项目累计多次运算后误差最多能差出好几毛养老院财务对不上就要从每天几十笔流水里重新核属于血泪教训。账单单据里还应该再加一个快照字段像care_level_snapshot这样的字段存生成账单当时的护理等级名称和单价这样后续调价不影响历史单据的追溯。3.3 设计表结构时容易忽略的三个索引细节第一所有外键关联字段都必须加索引。之前排查过一个养老系统接口慢的问题老人在住列表查询语句跑了将近三秒执行计划里全是全表扫描就是因为charge_bill表上elder_id没加索引。MySQL 不会自动为外键创建索引还得在建表时显式加。第二在住老人的列表页要按checkin_date排序所以checkin_date字段最好和status建联合索引两列顺序是 status 在前、checkin_date 在后。对在住老人列表的筛选来说这个索引能让查询直接走索引覆盖。第三退住时间字段会经常用来做区间统计例如退住人数月度趋势此时需要考虑按checkout_date建索引。大多数护理系统只统计在住人数却忽略退住分析所以中州养老系统的报表模块如果做了这一项说明业务设计比较周全。4. 用 Java 实现养老费用结算与护理排班核心代码、参数与调整方法4.1 月度费用结算的按天折算金额计算必须用 BigDecimal在养老业务里费用结算是单点最容易出 bug 的地方因为“整月费用”和“不足一个月”的折算规则并不是简单用总费用除以 30。老人在月中入住或退住床位费怎么算、伙食费怎么算、护理费又怎么算一旦规则不一致就会引来家属投诉。我一般会先把规则直接写进代码注释里方便后续接手的人核对。业务流程是先取出老人的入住日期、退住日期可空、床位费和护理费单价再按自然月做日费用折算。public BigDecimal calcMonthlyFee(LocalDate checkinDate, BigDecimal monthlyFee, LocalDate billStart, LocalDate billEnd) { // 账单区间为某月自然日如 2024-08-01 至 2024-08-31 LocalDate effectiveStart checkinDate.isAfter(billStart) ? checkinDate : billStart; LocalDate effectiveEnd (billEnd null) ? billEnd : billEnd; // 在住则以账单月底为截止 int daysInMonth billStart.lengthOfMonth(); // 不足整月按实际天数折算整月则直接用月费 if (effectiveStart.equals(billStart)) { return monthlyFee; } long days ChronoUnit.DAYS.between(effectiveStart, billEnd.plusDays(1)); BigDecimal dailyFee monthlyFee.divide(BigDecimal.valueOf(daysInMonth), 4, RoundingMode.HALF_UP); return dailyFee.multiply(BigDecimal.valueOf(days)).setScale(2, RoundingMode.HALF_UP); }这段逻辑里有一个取值动作值得单独说明monthlyFee.divide(..., 4, RoundingMode.HALF_UP)先保留四位小数然后乘实际天数最后再保留两位。先除后乘的顺序能减少累计误差如果哪一步直接写成两位小数多个账单叠加起来误差就可能变大。另外在住老人账单结束时终点取的是billEnd也就是当月的最后一天如果老人在月中退住那么在退住结算时会单独生成一张“退住结算单”把入住期间的未结费用连同押金退还一起做掉。费用结算的保存动作我把整套逻辑放进 service 层关键是用事务把“生成账单”和“更新老人状态”绑在一起。比如退住结算就需要在checkout方法上标注 Transactional 注解将退住时间回写、生成结算账单、更新床位状态三个操作放在同一个事务里任何一个失败都会整体回滚避免出现老人已退住但床位还占着的状态。4.2 护理排班怎么排轮转算法与任务批量生成护理排班的实现我见过两种做法简单方案是排班表里直接存“某护理员在某天负责哪些老人”每次手动指派更通用、也更省人力的方案是“模板轮转每日生成”。中州养老系统做的是后者。具体思路是护理员分为若干组每组对应一种班次轮转序列比如白班、夜班、休息、白班……系统按日期算出每个组当天应该执行哪个班次然后批量生成护理任务。public void generateDailyTasks(LocalDate day) { // 查出当天所有在住且护理计划为启用状态的老人 ListElderInfo elders elderMapper.selectList( new LambdaQueryWrapperElderInfo() .eq(ElderInfo::getStatus, 1) .eq(ElderInfo::getPlanEnabled, 1)); ListCareTask tasks new ArrayList(); for (ElderInfo elder : elders) { // 依据老人的护理等级获取计划任务模板 ListCarePlan plans carePlanMapper.selectList( new LambdaQueryWrapperCarePlan() .eq(CarePlan::getElderId, elder.getId())); for (CarePlan plan : plans) { CareTask task new CareTask(); task.setElderId(elder.getId()); task.setTaskName(plan.getTaskName()); task.setPlanTime(plan.getStartTime()); task.setPlanDate(day); task.setStatus(0); // 0 待执行 tasks.add(task); } } // 批量插入注意控制单批规模 if (!tasks.isEmpty()) { careTaskMapper.insertBatchSomeColumn(tasks); } }批量插入这里用了 MyBatis-Plus 的insertBatchSomeColumn方法它能把列表一次性插入数据库比循环单条插入效率高出很多。需要留心的是大批量插入时一次插入的条目数建议控制在 500 条以内通常可以先按每 200 条一批处理避免数据库单条 SQL 执行时间过长。有些 MyBatis-Plus 版本里insertBatchSomeColumn并不是内置的公共方法需要自己注一个自定义 SQL 注入器这块配套源码中一般已经做好了。排班执行后的回填也有一个坑任务完成时间、执行人、结果备注都要记录但不要直接去“更新”原本的任务记录而是要保留每次执行的历史。原因很简单护理员测完血压后可能复测要给家属看的是完整记录而不是覆盖前一条。4.3 护理等级调整时的联动更新中州养老系统有一个很容易被忽略的细节老人护理等级调整后不只是改一个字段已生成的当月护理计划和费用都要联动变化。月度账单还没有生成时调整等级直接改老人当前等级就行但如果当月账单已经生成就需要走“账单作废再重算”的流程作废后生成一张新的账单。这个场景在系统里通常体现为账单状态字段的流转未结、已结、已作废。调整等级的操作建议收敛在单独的服务方法里不要允许直接通过更新接口改等级字段否则月结时数据一定会乱。方法里先更新老人表再作废未结清的当月账单最后按新单价重算。这三步同样要放在同一事务内保证任何一步失败都不留半个状态。5. 中州养老系统避坑指南分页失效、金额精度、时间格式与权限漏配5.1 分页只返回了全部数据忘记注册 MyBatis-Plus 分页插件现象是列表页调用分页接口后返回的总记录数正确但每页总是把所有数据都查出来前端翻页无效。这个坑在我接手过的几个 Java 项目里都出现过最根本的原因是 MyBatis-Plus 的分页功能依赖一个内置拦截器没有配置它Page参数会被当成普通参数传进 SQL自然分不了页。解决方法是新建一个 MybatisPlusConfig 配置类把 PaginationInnerInterceptor 注册为 MyBatis-Plus 的插件Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这个配置类放在 config 包下启动时 Spring 会自动装配。业务代码里执行分页查询时要保证查询语句没有以自定义 SQL 的方式绕过拦截器。我一般建议在分页查询方法里直接打印 SQL 日志确认带有LIMIT关键字不要靠肉眼判断。5.2 账单金额出现 0.000000004 这种精度问题金额滥用 double现象是账单表中存了类似123.45000000000002的值前端展示时四舍五入看不出问题但一旦做多笔账单合计就出现一分钱误差。原因是 Java 里用double计算金额二进制浮点数无法精确表示十进制小数。解决方案是从源头杜绝 double数据库用DECIMAL(10,2)Java 实体类用BigDecimal所有运算一律走 BigDecimal禁止在代码里让 MySQL 做浮点乘法再返回给 Java 接收。如果数据库里已经有脏数据就需要写一次性脚本修正同时把代码里所有金额运算统一替换掉。5.3 时间返回给前端变成一串数字LocalDateTime 序列化问题现象是前端拿到2024-08-15T10:23:45或一串数字时间戳展示在页面上很不友好。原因是实体类用了 Java 8 的LocalDateTime但项目没配 Jackson 的 JavaTimeModule或者全局日期格式配置缺失。常见做法是在 application.yml 里统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这个配置只对java.util.Date类生效因此还需要单独引入 jackson-datatype-jsr310 依赖并加一个全局配置类来注册 JavaTimeModule。此外对于某些需要单独控制格式的字段比如账单的“生成时间”可以直接在实体类字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)。中州养老系统的源码如果同时存在这两种配置说明作者实际遇到过这个坑属于常规处理。5.4 护理员能查不在自己名下老人档案权限只控制了菜单没控制数据行现象是登录护理员账号后调用老人详情接口能查到任何老人的敏感健康信息。原因多半是后端接口没有做数据权限过滤仅靠前端菜单隐藏不能防止直接构造请求访问。解决思路是在查询层加一层行级权限拦截简单做法是在 Service 里判断当前登录用户的角色管理员可查全部护理员查自己负责的老人列表家属端口只查与本账号关联的老人。推荐在接口实现时统一走一个DataScope工具类内部先组装条件再传给 Mapper避免每个接口都手写权限判断造成遗漏。5.5 碰到“数据库字段下划线配不上实体类驼峰”导致查询列全部为 NULL现象是明明表里有数据但实体类字段全是 null这种问题常见于手工写的resultMap漏配了字段映射。MyBatis-Plus 默认开启驼峰转换但自定义 SQL 使用resultType时并不涉及 resultMap 映射逻辑应该没问题。真正会踩坑的是在 XML 里自定义结果集时没有加autoMappingtrue或者字段用别名AS careLevel又和驼峰策略冲突直接把查询结果列改成下划线别名并检查配置项map-underscore-to-camel-case: true就能解决。6. 从拿到源码到上线验证一个能帮你少走两个月弯路的做法源码拿回来后建议先别急着改功能先做一遍“接口自测 数据巡检”再动手。第一步是启动项目配置好数据源用 Swagger 或 Knife4j 把所有接口过一遍重点看三件事登录鉴权是否拦截了未携带 token 的请求、分页接口是否真的分页、老人列表与账单查询的时间字段格式是否正常。第二步是往数据库插入几组边界数据比如当月 1 日入住、当月 31 日退住、跨月退住和护理等级月中调整逐个跑费用结算接口核对金额是否正确。养老业务里这类边界数据最容易暴露折算逻辑 bug比写几百行测试代码都管用。第三步是验证排班生成逻辑把系统时间拨到下个月 1 号手动触发一次每日任务生成判断是否覆盖了跨月场景。做完验证再动手改业务也不迟。如果这套源码会用于生产环境部署时建议把 MySQL 换成 8.0 以上版本、加上 Redis 做会话缓存并且把默认的管理员初始密码改掉。后续做二次开发时常见的做法是在调度层加一个定时任务每天凌晨生成当日的护理任务这一步对源码的改动不大但对实际落地效果提升非常明显。这也是我每次接手养老系统源码后第一个做的改造从手动生成改成定时任务后管理员每天早上不用再点一次按钮使用体验完全是两回事。希望这套流程能帮你从拿到源码到稳定运行的路上少踩几个坑真正把精力花在业务功能迭代上。本文还有配套的精品资源点击获取