社区养老和传统养老院的管理逻辑差得很远工作人员要面对的是分散在社区里的大爷大妈、志愿者、第三方服务商还要把上门护理、健康档案、服务预约、工单派发这些又琐碎又必须闭环的事管起来。拿Spring Boot做一套社区养老服务管理系统确实是个很合适的练手项目springboot104这个编号对应的就是一套以老人档案为主线、以服务工单为抓手的后台管理系统。这套东西不光是课程设计里常见很多社区信息化改造也用类似的模式。如果你正准备做这类项目或者想搞清楚社区养老系统到底该怎么做这篇文章会从需求拆解到数据库设计再落到具体代码和部署排查给你一条能直接照做的路线。我实际做过三个版本的养老管理系统第一个版本光顾着堆功能结果服务预约和工单对不上老人信息重复录入后来推倒重来才把数据模型理顺。下面要讲的这些设计都是踩过坑之后沉淀下来的方案不保证每个场景都适用但至少能让你少走几周弯路。1. 项目概述与需求拆解1.1 养老服务系统的真实业务场景先想清楚一个问题社区养老服务系统和普通OA、CRM系统的核心差异在哪里普通系统管的是人和流程而养老系统管的是持续性的关怀责任。老人可能今天只需要助餐下周就要临时加一次康复理疗再过两个月可能转成长期护理。如果系统里只存一条静态档案后面的服务记录、健康变化全都接不上那这个系统就是一次性录入工具没有任何管理价值。我在需求调研时发现社区工作人员最头疼的不是某个老人的档案在哪而是这个老人上周的服务有没有完成家属昨天反映的问题处理到哪一步了哪位护理员今天上午有空档期。所以这套系统的核心业务场景可以拆成四条线档案线老人基础信息、家属联系方式、既往病史、用药情况、居住状态这是一个持续更新的动态库。服务线从家属或护工提交服务申请到管理员审核、派单给合适的护理员护理员上门打卡完成最后回访评价形成一条完整服务闭环。健康线定期记录血压、血糖、心率等体检数据通过趋势变化早发现身体异常这是社区养老区别于普通信息管理的关键点。管理线护理员排班、服务工单状态流转、服务量统计、满意度分析这些是管理人员每天要看的经营数据。很多新手一上来就画了十几个菜单觉得功能越多越好。实际上社区养老服务系统的核心价值就是让服务过程有迹可循。菜单再多如果没有把这些业务线串起来用起来就会非常别扭。1.2 功能模块的优先级划分面对一个实际项目不可能一口吃成胖子。我建议把功能模块分成三个优先级P0 必备模块老人档案管理、服务项目管理、服务预约与工单管理、护理员信息管理、用户登录与权限控制。没有这些系统跑不起来。P1 增强模块健康档案与趋势图表、服务回访与评价、工单统计报表、操作日志。没有这些系统能做但不能持续用。P2 拓展模块排班管理、消息提醒、老人位置定位、家属端微信小程序。这些是加分项初期可以留接口不做实现。这个项目的定位是社区养老服务管理系统不需要做成大而全的ERP。哪怕是毕业设计也要让评委看到你有业务理解能力而不是盲目堆模块。我当时做的时候P2只留了定时任务的空接口后面有需要再往里面填效果并不差。1.3 技术栈选型为什么是Spring Boot MyBatis-Plus MySQL说实话社区养老管理系统用Spring Boot做后端是再自然不过的选择网上资料多、招人门槛低、部署方便。但技术选型不是堆最新框架而是求稳。Spring Boot当前主流还是2.7.x系列推荐直接用2.7.18稳定而且兼容JDK8/11/17。除非你明确想体验Spring Boot 3否则不要让新版本依赖给你带来额外工作量。MyBatis-Plus比原生MyBatis省掉大量XML编写内置分页插件、代码生成器、LambdaQueryWrapper特别适合这种中小型管理系统。刚开始学的时候可能觉得魔法过多但用顺手后真的回不去了。MySQL 8.x社区养老的数据量不会大到需要分布式单库单表足够。MySQL 8的窗口函数、JSON字段偶尔能用上记得时区配置要统一。前端如果用Thymeleaf Bootstrap一个Java开发者就能搞定不需要拉上前端同事。如果团队有前端能力用Vue axios分离开发会更清爽。我这次讲的是Thymeleaf方案因为对初学者最友好。安全控制没有选择Spring Security因为这种系统角色固定、页面数量有限用一个拦截器 Session角色判断就足够。引入Spring Security意味着大量配置和学习成本性价比不高。这套组合的打法就是快速实现业务闭环同时保留后续优化的空间。等哪天并发上来、需求复杂了再升级安全框架也不迟。2. 数据库设计与核心表结构2.1 数据表整体规划思路数据库是这类管理系统的灵魂。你后端的Service写得再漂亮表结构不合理就必然到处补丁。我设计这套社区养老系统时遵循了三个原则以老人档案表为主表其他业务数据都通过elder_id关联不搞重复冗余的老人信息快照。服务预约和工单拆成两条记录预约记录描述想要什么服务工单记录描述谁来执行、执行到什么状态两者通过预约单号关联。所有状态字段用int类型保存不用字符串因为字符串容易写错、不易做查询优化配合枚举类在代码里转换即可。根据业务线划分我规划的物理表大约有九张功能域表名说明基础档案elder_info老人信息健康管理health_record健康检查记录服务资源service_item服务项目目录服务预订service_reserve服务预约单执行管理work_order服务工单人员管理worker_info护理员信息用户权限sys_user登录账号评价反馈service_eval回访评价日志sys_log操作日志这套表结构基本覆盖了P0和P1的功能需求而且表与表之间关系清楚后面写SQL统计时很顺手。2.2 核心表字段设计详解先看老人档案表elder_info。这张表决定了整个系统是否好用字段设计上既要有基础信息又要保留关键扩展字段id主键采用数据库自增不做雪花ID因为单机系统不需要分布式ID。name、gender、birth_date基础身份信息。id_card身份证号查询时常用建议建立唯一索引。如果涉及隐私可考虑加密存储但为了演示项目可暂时明文生产环境务必加密。phone、address联系方式与住址。社区服务最大的特点是上门所以地址要尽可能详细我甚至拆分了community_name和house_number两个字段。emergency_contact、emergency_phone紧急联系人信息必须有这个在实际场景中救过急。living_status居住状态比如1独居、2与子女同住、3养老机构独居老人是社区重点关注对象。chronic_disease慢性病史用逗号分隔存JSON数组的字符串形式方便展示。care_level照护等级1轻度/2中度/3重度这个字段直接关联服务工单派单逻辑。再来看服务预约表service_reserve。拿实际业务举例家属在手机上或前台申请每周二上午上门助浴这就是一条预约单elder_id关联老人。service_item_id关联服务项目。reserve_date、time_slot预约日期和时段比如上午/下午/晚上。remark家属备注。status预约状态0待审核、1已确认、2已取消、3已完成。而**服务工单表work_order**是执行层的记录同一个预约可以被拆成多次工单也可以一次预约对应一次工单。很多新手把预约和工单混在一张表后面一旦要做一次预约分两次服务就抓瞎。工单表的核心字段包括order_no工单号手动生成格式类似WO年月日四位序号方便线下核单。reserve_id关联预约单。worker_id负责的护理员。plan_start_time、actual_start_time、actual_end_time计划与实际执行时间。status工单状态机0待派单、1待服务、2服务中、3已完成、4已取消、5异常关闭。service_content实际操作内容用于存档。**健康记录表health_record**是社区养老的亮点我单独强调一下elder_id、record_date老人和日期。blood_pressure_high、blood_pressure_low血压高低压分别存字段不要合并成一个血压值字符串。heart_rate、blood_sugar、weight参考指标。is_abnormal是否异常1表示异常。这个字段不是用户录入的而是程序根据规则自动判断后续列表筛选近期有异常的老人就非常方便。2.3 状态机设计与事务边界状态字段不是随便加几个数字它对应的是业务流程。服务预约状态和工单状态必须分开管理两者之间的流转关系要提前定义清楚新增预约单service_reserve.status0此时还没有工单。管理员审核通过预约状态变为1同时生成一条work_order工单状态为0。管理员派单给护理员工单状态变为1此时护理员能看到自己的任务。护理员点击开始服务工单状态变为2点击完成状态变为3。服务完成后预约状态同步变为3。如果中途取消预约状态变为2同时当前未执行的工单状态变为4。这就意味着一次服务操作可能需要同时更新两张表。写代码时必须在事务里执行否则可能出现预约已经完成但工单还在服务中的不一致现象。我用的是Spring的Transactional注解只读操作不要加写操作一定加注意事务只在public方法上生效并且自调用不生效这是新手容易掉进的坑。3. 后端核心模块实现3.1 Spring Boot项目骨架搭建与基础配置项目我习惯用IntelliJ IDEA创建选择Spring Initializrgroup用com.communityartifact用service-system包名com.community.service。依赖选择上除了spring-boot-starter-web之外加上mybatis-plus-boot-starter、mysql-connector-java、lombok、validation和thymeleaf。这里有个小细节Spring Boot 2.7.x对应MyBatis-Plus 3.5.x不要用更早的版本否则分页插件配置会不兼容。在application.yml里我最常遇到的坑点是spring: datasource: url: jdbc:mysql://localhost:3306/community_service?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false prefix: classpath:/templates/ suffix: .html mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0serverTimezoneAsia/Shanghai这个必须写否则MySQL 8连接时区报错能把你逼疯。另外我把Thymeleaf缓存关闭改完页面刷新就能看到效果开发效率高不少。3.2 登录认证与拦截器实现不是所有页面都要登录才能进但核心业务页面必须受保护。我放弃Spring Security后用拦截器做了一套非常轻量的权限控制登录接口校验用户名密码成功后把用户对象和角色写入HttpSession。自定义一个AuthInterceptor实现HandlerInterceptor接口。通过preHandle方法检查Session里是否存在用户没有就重定向到登录页。对管理员专属的URL前缀比如/admin/**再加一层角色判断。注册拦截器时配置excludePathPatterns排除登录页、静态资源等路径。代码逻辑不复杂但要注意WebMvcConfigurer的写法Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/**) .excludePathPatterns(/login, /doLogin, /css/**, /js/**, /images/**); } }这里有个小坑Thymeleaf的静态资源放在classpath:/static/下如果你把静态页面放在templates里当成普通页面渲染拦截器排除路径可能对不上导致页面样式加载失败。我吃过一次亏后统一把CSS、JS、图片全放static下登录页用Controller渲染样式通过{/css/style.css}访问。密码存储一定要用加密算法我用的BCryptSpring Security的BCryptPasswordEncoder可以单独引包使用不用引入完整Spring Security。明文密码哪怕只在演示项目里出现也千万别干。3.3 服务预约与工单流转的业务闭环这是整个系统最核心的后端业务我从实际编码角度完整讲一遍。Controller层只做参数接收和结果封装不写业务。Service层处理预约和工单的状态流转。代码大致结构如下Service public class ReserveServiceImpl implements ReserveService { private final ReserveMapper reserveMapper; private final WorkOrderMapper workOrderMapper; Transactional(rollbackFor Exception.class) Override public boolean auditPass(Long reserveId, Long adminId) { ReserveEntity reserve reserveMapper.selectById(reserveId); if (reserve null || reserve.getStatus() ! 0) { throw new ServiceException(预约单不存在或状态不允许审核); } ReserveEntity update new ReserveEntity(); update.setId(reserveId); update.setStatus(1); reserveMapper.updateById(update); WorkOrderEntity workOrder new WorkOrderEntity(); workOrder.setReserveId(reserveId); workOrder.setElderId(reserve.getElderId()); workOrder.setServiceItemId(reserve.getServiceItemId()); workOrder.setStatus(0); workOrder.setOrderNo(generateOrderNo()); workOrderMapper.insert(workOrder); return true; } }这里尤其需要注意为什么不在审核时直接给工单指派护理员因为审核通过只代表服务可执行但哪天执行、谁执行可能还要再协调。把派单动作独立出来后续业务流程会灵活很多。工单派单给护理员时也要检查护理员当天该时段是否有已有冲突。我当时写了一个接口去查work_order表条件是同一worker、日期重叠、状态不是已取消。这个方法很有用但在一个演示项目里如果不想做太复杂可以先不做排班冲突检测但要留好数据库索引以防后面加功能时性能下降。护理员点击开始服务后更新actual_start_time状态从1变为2点击完成服务后更新actual_end_time状态变为3同时通过reserve_id反查预约单把预约状态也改为3。这一步必须放在一个事务里。如果你发现某个工单已经完成但预约还是审核状态通常就是这里忘了同步更新。3.4 健康档案与趋势统计的实现细节健康记录部分最核心的是一场基于时间序列的查询。比如前端要展示某位老人最近7次血压趋势SQL可以这么写SELECT blood_pressure_high, blood_pressure_low, heart_rate, record_date FROM health_record WHERE elder_id #{elderId} AND deleted 0 ORDER BY record_date DESC LIMIT 7不用复杂的分组统计简单查询后在Service层把结果反转成时间正序返回给前端绘制折线图就行。MyBatis-Plus里我是这样写的ListHealthRecord records healthRecordMapper.selectList( new LambdaQueryWrapperHealthRecord() .eq(HealthRecord::getElderId, elderId) .eq(HealthRecord::getDeleted, 0) .orderByDesc(HealthRecord::getRecordDate) .last(LIMIT 7) );这里有个容易被忽视的点record_date要按日期存储而不是带时间戳因为趋势查询关心的是天维度。如果你用datetime也不是不行但分组统计时要多写DATE()函数还容易带出时分秒干扰排序。is_abnormal字段的自动判断逻辑放在Service层比如收缩压大于140或舒张压大于90则标记异常。录入时执行判断不依赖前端传值。这样哪怕接口被直接调用数据也不会被伪造。统计报表方面一个典型的SQL是按月和护理员维度统计工单数SELECT worker_id, DATE_FORMAT(plan_start_time, %Y-%m) AS month, COUNT(*) AS total FROM work_order WHERE status 3 GROUP BY worker_id, DATE_FORMAT(plan_start_time, %Y-%m) ORDER BY month, total DESC拿到这个结果前端就可以做柱状图。有一点要注意工单数量统计时只应该把已完成状态算进去已取消和异常关闭的不算否则管理报表会虚高。4. 前端页面与交互设计4.1 Thymeleaf Bootstrap的页面组织前端页面我采用了Thymeleaf模板好处是后端能直接在HTML里渲染数据不需要跨域和接口层对开发速度极快。页面结构上我做了一个统一的侧边栏模板用Thymeleaf的th:fragment提取公共部分div th:fragmentsidebar a th:href{/index}首页面板/a a th:href{/elder/list}老人档案/a a th:href{/reserve/list}服务预约/a a th:href{/workorder/list}工单管理/a a th:href{/health/list}健康记录/a a th:href{/worker/list}护理员管理/a /div然后每个页面通过th:replace引入。这个方式比复制粘贴一万遍侧边栏代码强太多。如果你要改菜单只需要改一个地方。表格展示我直接用table classtable table-bordered加Bootstrap的样式配合后端分页插件返回的IPage对象把current、pages、records等传入前端。这里要特别注意如果你用MyBatis-Plus分页必须在配置类里定义MybatisPlusInterceptor这个Bean并且注册PaginationInnerInterceptor否则分页查询不生效返回的还是全量数据。这个坑反馈率极高。分页组件我手写了一套简化版不额外引前端插件。翻页链接直接拼?page1这种参数后端Controller读取页面参数。新手用这套能快速跑通。4.2 表单校验与二次确认机制表单校验分两层。前端用HTML5的required、maxlength做非空和长度拦截后端再用JSR-303的NotNull、Size做二次校验。我只信任后端的校验前端只是体验优化。服务预约表单里老人下拉框需要从后端查已入库老人列表我用Model把ListElderEntity塞进页面用th:each循环渲染。这里有个细节如果老人列表很长下拉框会很难用至少要按姓名关键字做模糊搜索。一开始我没做搜索社区的人找了20分钟才找到目标老人体验非常差。后面加了elder/select2这种接口用原生input监听输入事件动态加载匹配列表。工单派单的流程我建议在点击派单时弹出模态框显示工单号、服务项目、预约时间并让管理员选择护理员。模态框提交用AJAX不用整页刷新$.ajax({ url: /workorder/assign, type: POST, data: { workOrderId: workOrderId, workerId: workerId }, success: function(res) { if (res.code 200) { location.reload(); } else { alert(res.msg); } } });这里我踩过坑AJAX提交时忘记加Content-Type默认表单提交没问题但如果后端用RequestBody接收JSON就必须设置contentType: application/json。为了避免混淆统一写POST表单格式后端用普通参数接收别混用。4.3 健康趋势图表展示图表我用了ECharts因为它引入简单、文档全、图表类型够用。在health/detail.html页面里先放一个表格展示最近健康记录再放一个div idchart作为图表容器。后端返回给页面的数据格式是两列日期和值。我直接用Thymeleaf的th:inlinejavascript把数据转换成JS数组。script th:inlinejavascript var dates [[${dates}]]; var highPressure [[${highPressures}]]; var lowPressure [[${lowPressures}]]; /scriptECharts配置这里不展开了但有一个建议趋势图只展示最近30条数据过多折线点密密麻麻反而看不清。如果数据集很大后端做好分页限制前端循环绑定。4.4 角色差异化的前端展示系统里有三种角色管理员、社区工作人员、护理员。不同角色登录后看到的菜单应该不一样。我用Session里保存的角色通过Thymeleaf的条件表达式控制菜单显示div classmenu-item th:if${session.user.role 1} 管理后台入口 /div div classmenu-item th:if${session.user.role 2} 服务预约审核 /div div classmenu-item th:if${session.user.role 3} 我的工单 /div这种方式实现简单但由于按钮级权限控制的粒度比较粗如果后面要精确到接口权限还是要引入权限框架。对社区业务场景来说角色级别控制已经能满足九成需求。5. 部署上线与常见问题排查5.1 本地跑通的完整步骤拿到项目后第一步不是急着敲代码而是先把项目跑起来。我按照下面的顺序操作在本地MySQL创建数据库community_service字符集选utf8mb4排序规则选utf8mb4_general_ci。执行项目中提供的schema.sql和data.sql把表结构和初始账号数据导入。修改application.yml里的数据库账号密码。启动Spring Boot应用访问http://localhost:8080/。使用初始管理员账号登录检查首页是否正常展示统计卡。这里有个关键建议数据库初始化脚本一定要单独放到src/main/resources/db/目录下并且注释清楚每张表的用途。有些同学喜欢直接在Navicat里手建表然后让别人从数据库导出这样换电脑开发时极其痛苦。我自己曾经因为没管理好数据库脚本导致版本回退的时候只能靠记忆重建表浪费了一整晚。5.2 运行时常见的异常与解决办法我整理了一份高频问题清单这几乎是我在社区项目答疑时必发的症状原因解决方案启动报Access denied for user数据库账号密码错误或权限不足检查application.yml配置确认能通过命令行客户端连接启动报Server returns invalid timezoneMySQL时区未设置URL加serverTimezoneAsia/Shanghai或者在MySQL执行set global time_zone8:00页面中文乱码数据库表字符集不是utf8mb4或连接字符集不对确认库表和字段字符集URL加characterEncodingutf8列表页无分页效果分页拦截器未注册在配置类中注入MybatisPlusInterceptor和分页插件上传文件后访问404静态资源映射问题确认文件保存路径和映射路径匹配调试URL是否被拦截器拦截修改页面不生效Thymeleaf缓存未关闭开发环境配置spring.thymeleaf.cachefalse登录后点击退出还是能访问页面拦截器没有拦截该路径检查addPathPatterns通配符写法确认Session是否真正失效排查这些问题的最快捷方式是把MyBatis-Plus的log-impl设置为StdOutImpl在控制台看到所有SQL。然后再根据SQL执行是否正常来定位比盲猜前端还是后端的问题高效得多。5.3 安全细节与性能优化建议社区养老管理系统的安全级不能低。虽然赶工期但有几个底线不能碰密码必须加密我用的BCrypt加盐哪怕数据库泄露也不能直接知道明文密码。防止SQL注入MyBatis-Plus的LambdaQueryWrapper参数是用#{}预编译的不要手工拼SQL字符串。接口幂等性比如工单完成按钮如果网络卡顿用户可能会重复点击。前端按钮要置灰后端要再加一个检查工单状态是否为服务中的判断避免重复完成。数据权限护理员登录后只能看自己的工单不要给全部工单的查询权限列表查询SQL里必须加worker_id #{currentUserId}。性能方面这种系统并发不会太高但可以提前做两件事一是核心查询字段加索引比如elder_info.phone、work_order.worker_id、work_order.status二是列表接口避免select *只查需要的字段。数据库里老人和工单表的时间字段如果不建索引统计查询功能一上线就会越来越慢。6. 功能测试与演示准备6.1 测试用例设计思路交付前我会先按业务闭环走一遍流程。以一个虚拟老人为例管理员录入老人档案包含姓名、地址、护理等级。管理员添加一条该老人的健康记录血压偏高is_abnormal自动变为1。家属提交助浴服务预约。管理员审核预约自动生成工单。管理员派工单给某位护理员。护理员登录系统在我的工单列表里能看到该任务。护理员变更工单为开始、完成。确认预约状态同步变为已完成。管理员查看统计报表能看到服务量数据。这一步如果在手工测试中发现某处断掉说明业务链的某个环节没有闭环必须立刻修复。我曾经漏掉完成工单后同步预约状态这一环节被测试同学直接打回后来才补上事务代码。6.2 演示环境的数据准备如果是做项目答辩给评委看千万不要只用一个空库演示足够场景化。我会准备好10个真实的老人档案名字都是常见姓氏住址分布在不同小区。5个护理员不同等级和技能标签。30条健康记录横跨三个月能明显看出趋势变化。20条服务工单包含已完成、待服务、已取消等多种状态。一两张ECharts图表能直接看到统计效果。数据准备这一步看着简单但很花时间。我的做法是写一个小工具类模拟生成数据一次性插入。你也直接在数据库里手动造数据但效率低且容易遗漏字段。6.3 项目文档与代码版本管理写代码之外项目要能持续改进离不开一套基础文档README.md项目简介、技术栈、运行步骤放最前面。database.sql建表语句和初始数据注释清晰。docs/需求文档.md记录功能清单和非功能需求。docs/接口文档.mdController层核心接口路径、入参、返回。我在代码里使用Git管理每次提交信息写清楚新增派单功能修复工单状态更新bug这样回滚时快速定位。参加毕业设计或者项目展示Git提交记录本身也是你工作量最好的证明。7. 常见问题与排查技巧实录7.1 我对两个高频Bug的排查记录第一个问题是页面显示没问题但数据库中文乱码。当时我查了一圈发现数据库表和字段都是utf8但连接URL没有加characterEncodingutf8导致驱动用了系统默认字符集。这是一个低级但很常见的坑后来我在代码审计时专门加了规则提醒自己。第二个问题是分页查询失效。前端翻页正常返回数据但后端的IPage里getTotal()一直是0而且查询出来的记录数是全量。排查后发现是MybatisPlusInterceptor没有注册成功因为配置类上忘了加Configuration注解导致分页插件没有被Spring容器管理。这个问题让我深刻意识到框架的自动配置并不是真的全自动。7.2 排查问题的思路框架我总结出一个排查问题的小框架特别适合新手先分清楚是哪一层的问题浏览器F12看Network请求是否成功、返回什么状态码。如果请求成功但数据不对再看后端Controller接口返回的JSON或日志输出。如果接口数据有问题打开SQL日志检查执行SQL是否符合预期。如果SQL正确但结果不对回查数据库里的数据是不是脏数据或字段类型不对。如果都没问题再考虑是不是缓存、Session或线程并发导致。绝大多数时候问题都能被这五步定位到。不要一上来就重启服务、清缓存那样效率很低。7.3 最后一个独家技巧规范统一返回体在项目里我定义了一个统一的返回结果类ResultT包含code、msg、data字段。所有Controller接口都返回这个对象AJAX请求通过res.code判断成功与否。这个习惯一开始看起来多花了一点代码但后续排查问题和前后端分离改造时带来非常大的便利。之前的项目就是因为每个接口返回结构都不一样前端写大量分支判断后来统一规范后代码一下清爽了很多。我认为哪怕你只是一个人做项目也一定要有统一返回体意识这是一分投入十分回报的设计。社区养老管理系统看着只是个普通CRUD项目但真做进去从表结构设计、状态机流转到权限控制每一层都有需要琢磨的地方。我做这个项目最深的感觉是业务闭环比技术炫技重要得多流程上断了一个环节系统就是半残品。尤其是服务预约和工单这部分一定要自己先把业务从头到尾走通再去优化代码。如果你正在做同类型项目建议先别急着写页面花两天整理表结构和状态流转后面开发速度会快好几倍。这套方案算是我自己趟出来的经验实际项目里你肯定会碰到新的细节问题但核心思路可以复用。最后再分享一个小技巧把工单状态、预约状态的枚举值打印成一张纸贴在电脑旁边写代码和排查数据时随时对照能少掉很多头发。
社区养老和传统养老院的管理逻辑差得很远工作人员要面对的是分散在社区里的大爷大妈、志愿者、第三方服务商还要把上门护理、健康档案、服务预约、工单派发这些又琐碎又必须闭环的事管起来。拿Spring Boot做一套社区养老服务管理系统确实是个很合适的练手项目springboot104这个编号对应的就是一套以老人档案为主线、以服务工单为抓手的后台管理系统。这套东西不光是课程设计里常见很多社区信息化改造也用类似的模式。如果你正准备做这类项目或者想搞清楚社区养老系统到底该怎么做这篇文章会从需求拆解到数据库设计再落到具体代码和部署排查给你一条能直接照做的路线。我实际做过三个版本的养老管理系统第一个版本光顾着堆功能结果服务预约和工单对不上老人信息重复录入后来推倒重来才把数据模型理顺。下面要讲的这些设计都是踩过坑之后沉淀下来的方案不保证每个场景都适用但至少能让你少走几周弯路。1. 项目概述与需求拆解1.1 养老服务系统的真实业务场景先想清楚一个问题社区养老服务系统和普通OA、CRM系统的核心差异在哪里普通系统管的是人和流程而养老系统管的是持续性的关怀责任。老人可能今天只需要助餐下周就要临时加一次康复理疗再过两个月可能转成长期护理。如果系统里只存一条静态档案后面的服务记录、健康变化全都接不上那这个系统就是一次性录入工具没有任何管理价值。我在需求调研时发现社区工作人员最头疼的不是某个老人的档案在哪而是这个老人上周的服务有没有完成家属昨天反映的问题处理到哪一步了哪位护理员今天上午有空档期。所以这套系统的核心业务场景可以拆成四条线档案线老人基础信息、家属联系方式、既往病史、用药情况、居住状态这是一个持续更新的动态库。服务线从家属或护工提交服务申请到管理员审核、派单给合适的护理员护理员上门打卡完成最后回访评价形成一条完整服务闭环。健康线定期记录血压、血糖、心率等体检数据通过趋势变化早发现身体异常这是社区养老区别于普通信息管理的关键点。管理线护理员排班、服务工单状态流转、服务量统计、满意度分析这些是管理人员每天要看的经营数据。很多新手一上来就画了十几个菜单觉得功能越多越好。实际上社区养老服务系统的核心价值就是让服务过程有迹可循。菜单再多如果没有把这些业务线串起来用起来就会非常别扭。1.2 功能模块的优先级划分面对一个实际项目不可能一口吃成胖子。我建议把功能模块分成三个优先级P0 必备模块老人档案管理、服务项目管理、服务预约与工单管理、护理员信息管理、用户登录与权限控制。没有这些系统跑不起来。P1 增强模块健康档案与趋势图表、服务回访与评价、工单统计报表、操作日志。没有这些系统能做但不能持续用。P2 拓展模块排班管理、消息提醒、老人位置定位、家属端微信小程序。这些是加分项初期可以留接口不做实现。这个项目的定位是社区养老服务管理系统不需要做成大而全的ERP。哪怕是毕业设计也要让评委看到你有业务理解能力而不是盲目堆模块。我当时做的时候P2只留了定时任务的空接口后面有需要再往里面填效果并不差。1.3 技术栈选型为什么是Spring Boot MyBatis-Plus MySQL说实话社区养老管理系统用Spring Boot做后端是再自然不过的选择网上资料多、招人门槛低、部署方便。但技术选型不是堆最新框架而是求稳。Spring Boot当前主流还是2.7.x系列推荐直接用2.7.18稳定而且兼容JDK8/11/17。除非你明确想体验Spring Boot 3否则不要让新版本依赖给你带来额外工作量。MyBatis-Plus比原生MyBatis省掉大量XML编写内置分页插件、代码生成器、LambdaQueryWrapper特别适合这种中小型管理系统。刚开始学的时候可能觉得魔法过多但用顺手后真的回不去了。MySQL 8.x社区养老的数据量不会大到需要分布式单库单表足够。MySQL 8的窗口函数、JSON字段偶尔能用上记得时区配置要统一。前端如果用Thymeleaf Bootstrap一个Java开发者就能搞定不需要拉上前端同事。如果团队有前端能力用Vue axios分离开发会更清爽。我这次讲的是Thymeleaf方案因为对初学者最友好。安全控制没有选择Spring Security因为这种系统角色固定、页面数量有限用一个拦截器 Session角色判断就足够。引入Spring Security意味着大量配置和学习成本性价比不高。这套组合的打法就是快速实现业务闭环同时保留后续优化的空间。等哪天并发上来、需求复杂了再升级安全框架也不迟。2. 数据库设计与核心表结构2.1 数据表整体规划思路数据库是这类管理系统的灵魂。你后端的Service写得再漂亮表结构不合理就必然到处补丁。我设计这套社区养老系统时遵循了三个原则以老人档案表为主表其他业务数据都通过elder_id关联不搞重复冗余的老人信息快照。服务预约和工单拆成两条记录预约记录描述想要什么服务工单记录描述谁来执行、执行到什么状态两者通过预约单号关联。所有状态字段用int类型保存不用字符串因为字符串容易写错、不易做查询优化配合枚举类在代码里转换即可。根据业务线划分我规划的物理表大约有九张功能域表名说明基础档案elder_info老人信息健康管理health_record健康检查记录服务资源service_item服务项目目录服务预订service_reserve服务预约单执行管理work_order服务工单人员管理worker_info护理员信息用户权限sys_user登录账号评价反馈service_eval回访评价日志sys_log操作日志这套表结构基本覆盖了P0和P1的功能需求而且表与表之间关系清楚后面写SQL统计时很顺手。2.2 核心表字段设计详解先看老人档案表elder_info。这张表决定了整个系统是否好用字段设计上既要有基础信息又要保留关键扩展字段id主键采用数据库自增不做雪花ID因为单机系统不需要分布式ID。name、gender、birth_date基础身份信息。id_card身份证号查询时常用建议建立唯一索引。如果涉及隐私可考虑加密存储但为了演示项目可暂时明文生产环境务必加密。phone、address联系方式与住址。社区服务最大的特点是上门所以地址要尽可能详细我甚至拆分了community_name和house_number两个字段。emergency_contact、emergency_phone紧急联系人信息必须有这个在实际场景中救过急。living_status居住状态比如1独居、2与子女同住、3养老机构独居老人是社区重点关注对象。chronic_disease慢性病史用逗号分隔存JSON数组的字符串形式方便展示。care_level照护等级1轻度/2中度/3重度这个字段直接关联服务工单派单逻辑。再来看服务预约表service_reserve。拿实际业务举例家属在手机上或前台申请每周二上午上门助浴这就是一条预约单elder_id关联老人。service_item_id关联服务项目。reserve_date、time_slot预约日期和时段比如上午/下午/晚上。remark家属备注。status预约状态0待审核、1已确认、2已取消、3已完成。而**服务工单表work_order**是执行层的记录同一个预约可以被拆成多次工单也可以一次预约对应一次工单。很多新手把预约和工单混在一张表后面一旦要做一次预约分两次服务就抓瞎。工单表的核心字段包括order_no工单号手动生成格式类似WO年月日四位序号方便线下核单。reserve_id关联预约单。worker_id负责的护理员。plan_start_time、actual_start_time、actual_end_time计划与实际执行时间。status工单状态机0待派单、1待服务、2服务中、3已完成、4已取消、5异常关闭。service_content实际操作内容用于存档。**健康记录表health_record**是社区养老的亮点我单独强调一下elder_id、record_date老人和日期。blood_pressure_high、blood_pressure_low血压高低压分别存字段不要合并成一个血压值字符串。heart_rate、blood_sugar、weight参考指标。is_abnormal是否异常1表示异常。这个字段不是用户录入的而是程序根据规则自动判断后续列表筛选近期有异常的老人就非常方便。2.3 状态机设计与事务边界状态字段不是随便加几个数字它对应的是业务流程。服务预约状态和工单状态必须分开管理两者之间的流转关系要提前定义清楚新增预约单service_reserve.status0此时还没有工单。管理员审核通过预约状态变为1同时生成一条work_order工单状态为0。管理员派单给护理员工单状态变为1此时护理员能看到自己的任务。护理员点击开始服务工单状态变为2点击完成状态变为3。服务完成后预约状态同步变为3。如果中途取消预约状态变为2同时当前未执行的工单状态变为4。这就意味着一次服务操作可能需要同时更新两张表。写代码时必须在事务里执行否则可能出现预约已经完成但工单还在服务中的不一致现象。我用的是Spring的Transactional注解只读操作不要加写操作一定加注意事务只在public方法上生效并且自调用不生效这是新手容易掉进的坑。3. 后端核心模块实现3.1 Spring Boot项目骨架搭建与基础配置项目我习惯用IntelliJ IDEA创建选择Spring Initializrgroup用com.communityartifact用service-system包名com.community.service。依赖选择上除了spring-boot-starter-web之外加上mybatis-plus-boot-starter、mysql-connector-java、lombok、validation和thymeleaf。这里有个小细节Spring Boot 2.7.x对应MyBatis-Plus 3.5.x不要用更早的版本否则分页插件配置会不兼容。在application.yml里我最常遇到的坑点是spring: datasource: url: jdbc:mysql://localhost:3306/community_service?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false prefix: classpath:/templates/ suffix: .html mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0serverTimezoneAsia/Shanghai这个必须写否则MySQL 8连接时区报错能把你逼疯。另外我把Thymeleaf缓存关闭改完页面刷新就能看到效果开发效率高不少。3.2 登录认证与拦截器实现不是所有页面都要登录才能进但核心业务页面必须受保护。我放弃Spring Security后用拦截器做了一套非常轻量的权限控制登录接口校验用户名密码成功后把用户对象和角色写入HttpSession。自定义一个AuthInterceptor实现HandlerInterceptor接口。通过preHandle方法检查Session里是否存在用户没有就重定向到登录页。对管理员专属的URL前缀比如/admin/**再加一层角色判断。注册拦截器时配置excludePathPatterns排除登录页、静态资源等路径。代码逻辑不复杂但要注意WebMvcConfigurer的写法Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/**) .excludePathPatterns(/login, /doLogin, /css/**, /js/**, /images/**); } }这里有个小坑Thymeleaf的静态资源放在classpath:/static/下如果你把静态页面放在templates里当成普通页面渲染拦截器排除路径可能对不上导致页面样式加载失败。我吃过一次亏后统一把CSS、JS、图片全放static下登录页用Controller渲染样式通过{/css/style.css}访问。密码存储一定要用加密算法我用的BCryptSpring Security的BCryptPasswordEncoder可以单独引包使用不用引入完整Spring Security。明文密码哪怕只在演示项目里出现也千万别干。3.3 服务预约与工单流转的业务闭环这是整个系统最核心的后端业务我从实际编码角度完整讲一遍。Controller层只做参数接收和结果封装不写业务。Service层处理预约和工单的状态流转。代码大致结构如下Service public class ReserveServiceImpl implements ReserveService { private final ReserveMapper reserveMapper; private final WorkOrderMapper workOrderMapper; Transactional(rollbackFor Exception.class) Override public boolean auditPass(Long reserveId, Long adminId) { ReserveEntity reserve reserveMapper.selectById(reserveId); if (reserve null || reserve.getStatus() ! 0) { throw new ServiceException(预约单不存在或状态不允许审核); } ReserveEntity update new ReserveEntity(); update.setId(reserveId); update.setStatus(1); reserveMapper.updateById(update); WorkOrderEntity workOrder new WorkOrderEntity(); workOrder.setReserveId(reserveId); workOrder.setElderId(reserve.getElderId()); workOrder.setServiceItemId(reserve.getServiceItemId()); workOrder.setStatus(0); workOrder.setOrderNo(generateOrderNo()); workOrderMapper.insert(workOrder); return true; } }这里尤其需要注意为什么不在审核时直接给工单指派护理员因为审核通过只代表服务可执行但哪天执行、谁执行可能还要再协调。把派单动作独立出来后续业务流程会灵活很多。工单派单给护理员时也要检查护理员当天该时段是否有已有冲突。我当时写了一个接口去查work_order表条件是同一worker、日期重叠、状态不是已取消。这个方法很有用但在一个演示项目里如果不想做太复杂可以先不做排班冲突检测但要留好数据库索引以防后面加功能时性能下降。护理员点击开始服务后更新actual_start_time状态从1变为2点击完成服务后更新actual_end_time状态变为3同时通过reserve_id反查预约单把预约状态也改为3。这一步必须放在一个事务里。如果你发现某个工单已经完成但预约还是审核状态通常就是这里忘了同步更新。3.4 健康档案与趋势统计的实现细节健康记录部分最核心的是一场基于时间序列的查询。比如前端要展示某位老人最近7次血压趋势SQL可以这么写SELECT blood_pressure_high, blood_pressure_low, heart_rate, record_date FROM health_record WHERE elder_id #{elderId} AND deleted 0 ORDER BY record_date DESC LIMIT 7不用复杂的分组统计简单查询后在Service层把结果反转成时间正序返回给前端绘制折线图就行。MyBatis-Plus里我是这样写的ListHealthRecord records healthRecordMapper.selectList( new LambdaQueryWrapperHealthRecord() .eq(HealthRecord::getElderId, elderId) .eq(HealthRecord::getDeleted, 0) .orderByDesc(HealthRecord::getRecordDate) .last(LIMIT 7) );这里有个容易被忽视的点record_date要按日期存储而不是带时间戳因为趋势查询关心的是天维度。如果你用datetime也不是不行但分组统计时要多写DATE()函数还容易带出时分秒干扰排序。is_abnormal字段的自动判断逻辑放在Service层比如收缩压大于140或舒张压大于90则标记异常。录入时执行判断不依赖前端传值。这样哪怕接口被直接调用数据也不会被伪造。统计报表方面一个典型的SQL是按月和护理员维度统计工单数SELECT worker_id, DATE_FORMAT(plan_start_time, %Y-%m) AS month, COUNT(*) AS total FROM work_order WHERE status 3 GROUP BY worker_id, DATE_FORMAT(plan_start_time, %Y-%m) ORDER BY month, total DESC拿到这个结果前端就可以做柱状图。有一点要注意工单数量统计时只应该把已完成状态算进去已取消和异常关闭的不算否则管理报表会虚高。4. 前端页面与交互设计4.1 Thymeleaf Bootstrap的页面组织前端页面我采用了Thymeleaf模板好处是后端能直接在HTML里渲染数据不需要跨域和接口层对开发速度极快。页面结构上我做了一个统一的侧边栏模板用Thymeleaf的th:fragment提取公共部分div th:fragmentsidebar a th:href{/index}首页面板/a a th:href{/elder/list}老人档案/a a th:href{/reserve/list}服务预约/a a th:href{/workorder/list}工单管理/a a th:href{/health/list}健康记录/a a th:href{/worker/list}护理员管理/a /div然后每个页面通过th:replace引入。这个方式比复制粘贴一万遍侧边栏代码强太多。如果你要改菜单只需要改一个地方。表格展示我直接用table classtable table-bordered加Bootstrap的样式配合后端分页插件返回的IPage对象把current、pages、records等传入前端。这里要特别注意如果你用MyBatis-Plus分页必须在配置类里定义MybatisPlusInterceptor这个Bean并且注册PaginationInnerInterceptor否则分页查询不生效返回的还是全量数据。这个坑反馈率极高。分页组件我手写了一套简化版不额外引前端插件。翻页链接直接拼?page1这种参数后端Controller读取页面参数。新手用这套能快速跑通。4.2 表单校验与二次确认机制表单校验分两层。前端用HTML5的required、maxlength做非空和长度拦截后端再用JSR-303的NotNull、Size做二次校验。我只信任后端的校验前端只是体验优化。服务预约表单里老人下拉框需要从后端查已入库老人列表我用Model把ListElderEntity塞进页面用th:each循环渲染。这里有个细节如果老人列表很长下拉框会很难用至少要按姓名关键字做模糊搜索。一开始我没做搜索社区的人找了20分钟才找到目标老人体验非常差。后面加了elder/select2这种接口用原生input监听输入事件动态加载匹配列表。工单派单的流程我建议在点击派单时弹出模态框显示工单号、服务项目、预约时间并让管理员选择护理员。模态框提交用AJAX不用整页刷新$.ajax({ url: /workorder/assign, type: POST, data: { workOrderId: workOrderId, workerId: workerId }, success: function(res) { if (res.code 200) { location.reload(); } else { alert(res.msg); } } });这里我踩过坑AJAX提交时忘记加Content-Type默认表单提交没问题但如果后端用RequestBody接收JSON就必须设置contentType: application/json。为了避免混淆统一写POST表单格式后端用普通参数接收别混用。4.3 健康趋势图表展示图表我用了ECharts因为它引入简单、文档全、图表类型够用。在health/detail.html页面里先放一个表格展示最近健康记录再放一个div idchart作为图表容器。后端返回给页面的数据格式是两列日期和值。我直接用Thymeleaf的th:inlinejavascript把数据转换成JS数组。script th:inlinejavascript var dates [[${dates}]]; var highPressure [[${highPressures}]]; var lowPressure [[${lowPressures}]]; /scriptECharts配置这里不展开了但有一个建议趋势图只展示最近30条数据过多折线点密密麻麻反而看不清。如果数据集很大后端做好分页限制前端循环绑定。4.4 角色差异化的前端展示系统里有三种角色管理员、社区工作人员、护理员。不同角色登录后看到的菜单应该不一样。我用Session里保存的角色通过Thymeleaf的条件表达式控制菜单显示div classmenu-item th:if${session.user.role 1} 管理后台入口 /div div classmenu-item th:if${session.user.role 2} 服务预约审核 /div div classmenu-item th:if${session.user.role 3} 我的工单 /div这种方式实现简单但由于按钮级权限控制的粒度比较粗如果后面要精确到接口权限还是要引入权限框架。对社区业务场景来说角色级别控制已经能满足九成需求。5. 部署上线与常见问题排查5.1 本地跑通的完整步骤拿到项目后第一步不是急着敲代码而是先把项目跑起来。我按照下面的顺序操作在本地MySQL创建数据库community_service字符集选utf8mb4排序规则选utf8mb4_general_ci。执行项目中提供的schema.sql和data.sql把表结构和初始账号数据导入。修改application.yml里的数据库账号密码。启动Spring Boot应用访问http://localhost:8080/。使用初始管理员账号登录检查首页是否正常展示统计卡。这里有个关键建议数据库初始化脚本一定要单独放到src/main/resources/db/目录下并且注释清楚每张表的用途。有些同学喜欢直接在Navicat里手建表然后让别人从数据库导出这样换电脑开发时极其痛苦。我自己曾经因为没管理好数据库脚本导致版本回退的时候只能靠记忆重建表浪费了一整晚。5.2 运行时常见的异常与解决办法我整理了一份高频问题清单这几乎是我在社区项目答疑时必发的症状原因解决方案启动报Access denied for user数据库账号密码错误或权限不足检查application.yml配置确认能通过命令行客户端连接启动报Server returns invalid timezoneMySQL时区未设置URL加serverTimezoneAsia/Shanghai或者在MySQL执行set global time_zone8:00页面中文乱码数据库表字符集不是utf8mb4或连接字符集不对确认库表和字段字符集URL加characterEncodingutf8列表页无分页效果分页拦截器未注册在配置类中注入MybatisPlusInterceptor和分页插件上传文件后访问404静态资源映射问题确认文件保存路径和映射路径匹配调试URL是否被拦截器拦截修改页面不生效Thymeleaf缓存未关闭开发环境配置spring.thymeleaf.cachefalse登录后点击退出还是能访问页面拦截器没有拦截该路径检查addPathPatterns通配符写法确认Session是否真正失效排查这些问题的最快捷方式是把MyBatis-Plus的log-impl设置为StdOutImpl在控制台看到所有SQL。然后再根据SQL执行是否正常来定位比盲猜前端还是后端的问题高效得多。5.3 安全细节与性能优化建议社区养老管理系统的安全级不能低。虽然赶工期但有几个底线不能碰密码必须加密我用的BCrypt加盐哪怕数据库泄露也不能直接知道明文密码。防止SQL注入MyBatis-Plus的LambdaQueryWrapper参数是用#{}预编译的不要手工拼SQL字符串。接口幂等性比如工单完成按钮如果网络卡顿用户可能会重复点击。前端按钮要置灰后端要再加一个检查工单状态是否为服务中的判断避免重复完成。数据权限护理员登录后只能看自己的工单不要给全部工单的查询权限列表查询SQL里必须加worker_id #{currentUserId}。性能方面这种系统并发不会太高但可以提前做两件事一是核心查询字段加索引比如elder_info.phone、work_order.worker_id、work_order.status二是列表接口避免select *只查需要的字段。数据库里老人和工单表的时间字段如果不建索引统计查询功能一上线就会越来越慢。6. 功能测试与演示准备6.1 测试用例设计思路交付前我会先按业务闭环走一遍流程。以一个虚拟老人为例管理员录入老人档案包含姓名、地址、护理等级。管理员添加一条该老人的健康记录血压偏高is_abnormal自动变为1。家属提交助浴服务预约。管理员审核预约自动生成工单。管理员派工单给某位护理员。护理员登录系统在我的工单列表里能看到该任务。护理员变更工单为开始、完成。确认预约状态同步变为已完成。管理员查看统计报表能看到服务量数据。这一步如果在手工测试中发现某处断掉说明业务链的某个环节没有闭环必须立刻修复。我曾经漏掉完成工单后同步预约状态这一环节被测试同学直接打回后来才补上事务代码。6.2 演示环境的数据准备如果是做项目答辩给评委看千万不要只用一个空库演示足够场景化。我会准备好10个真实的老人档案名字都是常见姓氏住址分布在不同小区。5个护理员不同等级和技能标签。30条健康记录横跨三个月能明显看出趋势变化。20条服务工单包含已完成、待服务、已取消等多种状态。一两张ECharts图表能直接看到统计效果。数据准备这一步看着简单但很花时间。我的做法是写一个小工具类模拟生成数据一次性插入。你也直接在数据库里手动造数据但效率低且容易遗漏字段。6.3 项目文档与代码版本管理写代码之外项目要能持续改进离不开一套基础文档README.md项目简介、技术栈、运行步骤放最前面。database.sql建表语句和初始数据注释清晰。docs/需求文档.md记录功能清单和非功能需求。docs/接口文档.mdController层核心接口路径、入参、返回。我在代码里使用Git管理每次提交信息写清楚新增派单功能修复工单状态更新bug这样回滚时快速定位。参加毕业设计或者项目展示Git提交记录本身也是你工作量最好的证明。7. 常见问题与排查技巧实录7.1 我对两个高频Bug的排查记录第一个问题是页面显示没问题但数据库中文乱码。当时我查了一圈发现数据库表和字段都是utf8但连接URL没有加characterEncodingutf8导致驱动用了系统默认字符集。这是一个低级但很常见的坑后来我在代码审计时专门加了规则提醒自己。第二个问题是分页查询失效。前端翻页正常返回数据但后端的IPage里getTotal()一直是0而且查询出来的记录数是全量。排查后发现是MybatisPlusInterceptor没有注册成功因为配置类上忘了加Configuration注解导致分页插件没有被Spring容器管理。这个问题让我深刻意识到框架的自动配置并不是真的全自动。7.2 排查问题的思路框架我总结出一个排查问题的小框架特别适合新手先分清楚是哪一层的问题浏览器F12看Network请求是否成功、返回什么状态码。如果请求成功但数据不对再看后端Controller接口返回的JSON或日志输出。如果接口数据有问题打开SQL日志检查执行SQL是否符合预期。如果SQL正确但结果不对回查数据库里的数据是不是脏数据或字段类型不对。如果都没问题再考虑是不是缓存、Session或线程并发导致。绝大多数时候问题都能被这五步定位到。不要一上来就重启服务、清缓存那样效率很低。7.3 最后一个独家技巧规范统一返回体在项目里我定义了一个统一的返回结果类ResultT包含code、msg、data字段。所有Controller接口都返回这个对象AJAX请求通过res.code判断成功与否。这个习惯一开始看起来多花了一点代码但后续排查问题和前后端分离改造时带来非常大的便利。之前的项目就是因为每个接口返回结构都不一样前端写大量分支判断后来统一规范后代码一下清爽了很多。我认为哪怕你只是一个人做项目也一定要有统一返回体意识这是一分投入十分回报的设计。社区养老管理系统看着只是个普通CRUD项目但真做进去从表结构设计、状态机流转到权限控制每一层都有需要琢磨的地方。我做这个项目最深的感觉是业务闭环比技术炫技重要得多流程上断了一个环节系统就是半残品。尤其是服务预约和工单这部分一定要自己先把业务从头到尾走通再去优化代码。如果你正在做同类型项目建议先别急着写页面花两天整理表结构和状态流转后面开发速度会快好几倍。这套方案算是我自己趟出来的经验实际项目里你肯定会碰到新的细节问题但核心思路可以复用。最后再分享一个小技巧把工单状态、预约状态的枚举值打印成一张纸贴在电脑旁边写代码和排查数据时随时对照能少掉很多头发。
