企业官网建设流程全解析

养老这块业务我这两年接触得不算少。之前做过几个社区康养相关的管理系统，最深的感受是：纯做信息化的系统很多，但真正懂业务、能把老人、家属、护理员、社区管理者这几个角色串起来的设计反而少见。所以看到这个“基于SpringBoot+Vue的养老智慧服务平台管理系统”的标题时，我第一反应是：这个系统的核心价值不在技术栈有多新，而在角色权限、服务流程和健康数据闭环这三个点能不能立住。

本文我会从业务建模、权限设计、核心模块实现、关键代码拆解、部署踩坑这几个维度，把一套完整可复现的养老智慧服务平台拆开讲清楚。技术栈就是标题里写的SpringBoot + Vue + MySQL + MyBatis，适合正在做毕设、或者刚入职想接触完整业务链路的Java后端开发者参考。如果你只想要源码自己改，我建议也先看明白每张表、每个接口背后的业务逻辑，不然改起来会很痛苦。

1. 养老服务平台首先要解决的不是技术问题，是角色问题

很多人在拿到这类题目时，第一反应是画ER图、建表、写CRUD。但真正跑过养老项目的人会告诉你：养老平台最核心的难点是——同一套系统要服务四类思维方式完全不同的用户。

1.1 四类核心角色的诉求差异

• 老人端（移动端/H5）：要极简，字号要大，按钮要少，操作不能超过两步。老人不会去学习“我的-服务记录-查看详情”这种三级菜单。我见过最离谱的设计是把服务预约做成表格+勾选，结果老人基本不会用。

• 家属端：要远程查看父母健康数据、缴费记录、服务工单状态，核心诉求是“不在身边但能掌握情况”。

• 服务人员端（护理员/保洁/助医等）：要接收派单、上传服务记录、上报异常，核心诉求是“少填表，多干活”。

• 管理员端（平台运营/社区管理者）：要审核人员、统计工单完成率、监控健康异常预警、处理投诉建议。核心诉求是“数据能说话”。

1.2 角色权限模型怎么设计才合理

我建议用经典的RBAC模型，但要注意一个细节：仅做菜单级别的权限控制是不够的，必须做到按钮级和字段级。

以Vue前端为例，我在权限控制上用了动态路由 + 按钮指令的方式：

// 动态路由：根据后端返回的权限码生成路由 const generateRoutes = (permissionCodes) => { const routeMap = { dashboard: () => import('@/views/Dashboard/index.vue'), elderList: () => import('@/views/Elder/list.vue'), serviceOrder: () => import('@/views/ServiceOrder/list.vue'), ... } return permissionCodes.filter(code => routeMap[code]).map(code => ({ path: `/${code}`, component: routeMap[code], meta: { title: MENU_MAP[code] } })) } // 按钮级权限指令 Vue.directive('permission', { inserted(el, binding) { const required = binding.value const hasPermission = store.getters.permissionCodes.includes(required) if (!hasPermission) { el.parentNode && el.parentNode.removeChild(el) } } })

后端用拦截器统一校验接口权限，前端只是做体验优化，真正的安全边界必须放在后端。比如@PreAuthorize("hasRole('ADMIN')")这种注解，或者自定义的@RequirePermission("service:order:assign")注解，我更推荐后者，因为角色会变，权限码不会变。

1.3 为什么Java + MySQL + MyBatis这个组合在养老项目里很稳

养老服务的业务特点是：并发量不大（一个社区千把老人），但事务链路长（预约-派单-服务-回访-结算-归档），报表查询复杂（月度服务统计、健康趋势分析）。MySQL完全够用，MyBatis对复杂SQL的控制力比JPA强很多，SpringBoot则把这些串起来非常丝滑。

我选型时的判断标准是：没有大数据量、没有高并发，核心是业务状态机和数据审计。这种项目用不上微服务，把一个单体应用写好、写规范，比拆一堆没必要的服务实用得多。

2. 数据库设计：养老服务的关键是“一张主表管全程”

这张图很重要：养老服务的每一笔业务，从老人发起预约开始，到服务完成、回访评价、费用结算，能不能用一条数据链路追踪到底？很多项目失败在数据表各管各的，服务订单关联不到健康档案，健康档案关联不到用药记录，报表根本出不来。

2.1 核心表结构拆解

我设计的核心表总共11张左右，这里挑最重要的5张说：

老人档案表（elder_info）

需要注意：身份证号建议加密存储，前端展示脱敏。我用的做法是属性加解密，存库是密文，出参自动脱敏。

服务工单表（service_order）

这个表是整个系统的业务主干：

工单状态机是这类系统的核心：

待派单(0) -> 已派单(1) -> 服务中(2) -> 已完成(3) -> 已评价(4) 待派单(0) -> 已取消(-1) 已派单(1) -> 服务人员确认后 -> 服务中(2) 服务中(2) -> 异常上报 -> 异常待处理(5)

健康监测表（health_record）

这里我要多说一句：健康数据是最容易做但又最容易被忽略业务深度的模块。很多系统只是存起来展示，真正有价值的逻辑是阈值预警。后面会详细讲。

2.2 建表时的几个关键经验

第一，所有业务表都要带created_time和updated_time，并且用MyBatis的自动填充来处理，不要每处手动set。第二，逻辑删除用deleted字段，不要物理删。第三，金额字段用decimal(10,2)，绝不用float。第四，手机号、身份证等敏感字段要么加密，要么脱敏，这个在养老场景尤其重要，涉及个人隐私合规。

3. 后端架构与核心接口设计：SpringBoot + MyBatis的组合实战

后端我用的是经典的三层架构，但加了一个我认为养老服务必须有的层：业务状态机层。

3.1 项目目录结构

com.demo.eldercare ├── config # 全局配置：跨域、拦截器、MyBatis分页 ├── controller # REST接口层 ├── service # 业务层 │ ├── impl # 业务实现 │ └── state # 工单状态机 ├── mapper # MyBatis DAO层 ├── entity # 实体类 ├── dto # 入参/出参对象 ├── vo # 视图对象 ├── common # 统一返回体、异常处理、工具类 └── task # 定时任务（健康预警、工单超时提醒）

3.2 统一返回体设计

这类管理系统，前后端交互的统一返回体一定要从一开始就定好。我用的是code + message + data结构：

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "success"; result.data = data; return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.code = 500; result.message = message; return result; } }

前端Vue这边封装axios拦截器，遇到code非200时用ElementUI的Message统一弹错，业务代码里不需要每个接口都做判断。

3.3 工单状态机：用策略模式替代switch-case

这是我认为这个项目后端最有含金量的设计点。如果你是照着别人源码改，大概率会发现他们用的是if (status == 2 && action == "complete")这种写法。短时间跑通没问题，但一旦状态多了，代码会变成屎山。

我用的是简单的状态机 + 策略模式：

@Component public class OrderStatusHandler { @Autowired private List<IOrderActionHandler> handlers; // 状态流转：当前状态 + 动作 -> 状态变更 public void handle(Long orderId, OrderStatus currentStatus, OrderAction action) { Optional<OrderStatus> target = action.getTargetStatus(currentStatus); if (target.isEmpty()) { throw new BusinessException("非法的状态流转: " + currentStatus + " -> " + action); } // 业务前置校验 action.validate(orderId); // 更新状态，并记录流转日志 serviceOrderMapper.updateStatus(orderId, target.get(), action.getCode()); stateLogMapper.insert(StateLog.build(orderId, currentStatus, target.get(), action)); } }

IOrderActionHandler里每个动作对应一个实现类，比如AssignOrderAction、StartServiceAction、CompleteServiceAction、CancelOrderAction。这样做的好处是：每个状态的校验逻辑、关联业务（比如服务完成后自动生成结算单）都封装在自己类里，接口加状态不影响老逻辑。

3.4 定时任务：健康异常预警与工单超时提醒

养老系统的健康预警不能靠用户刷新页面来发现。我引入了SpringBoot自带的@Scheduled定时任务。

健康预警的逻辑是这样：

@Component public class HealthAlertTask { @Autowired private HealthRecordMapper healthRecordMapper; @Autowired private AlertService alertService; @Scheduled(cron = "0 */15 * * * ?") // 每15分钟扫描一次 public void scanAbnormalHealthRecords() { // 1. 查询近15分钟内新增的健康记录 List<HealthRecord> records = healthRecordMapper.selectRecentRecords(15); // 2. 遍历判断是否超过阈值 for (HealthRecord record : records) { List<String> abnormalItems = checkThreshold(record); if (!abnormalItems.isEmpty()) { // 3. 生成预警记录并推送给家属端 alertService.pushAlert(record.getElderId(), abnormalItems); // 4. 高风险额外短信通知 if (riskLevel == HIGH) { smsService.send(emergencyPhone, buildMsg(abnormalItems)); } } } } }

阈值判断要区分年龄段和疾病史。比如正常老人舒张压90以下是正常，但有高血压病史且正在服药的老人，舒张压85就需要注意了。这些标定值我放在health_threshold_config表里，管理员可以在后台调整，而不是写死在代码里。

工单超时提醒也很重要：工单状态为“待派单”超过2小时，自动提醒管理员；状态为“服务中”超过预约时段4小时，自动上报异常。这里用@Scheduled每半小时扫一遍即可，不需要上MQ和延迟队列，杀鸡不用牛刀。

4. 前端Vue的落地：页面骨架与老人端的极简交互

前端我用的是Vue2 + ElementUI（现在搭新项目可以考虑Vue3 + Element Plus，但Vue2生态在这个场景还是很稳的）。整体是典型的管理后台布局：左侧菜单、顶部导航、主内容区。

4.1 后台管理端页面结构

src ├── layout # 主布局 │ └── index.vue # 侧边栏+顶栏+内容区 ├── views │ ├── dashboard # 数据概览 │ ├── elder # 老人档案管理 │ ├── staff # 服务人员管理 │ ├── order # 工单管理 │ ├── health # 健康档案 │ ├── alarm # 预警中心 │ ├── finance # 费用结算 │ ├── system # 管理员与权限配置 └── router # 路由配置

数据概览我用的是ECharts，四个核心卡片：今日工单量、待派单数量、在管老人总数、本月预警次数。下面跟两个图表：近7天工单趋势（折线）、服务类型占比（饼图）。

4.2 老人端H5：不是做得好，而是做得够少

这个我很有感触。很多人在老人端堆功能，健康上传、商城购物、视频通话什么都塞进去。实际上我调研过多次，老人的核心需求就是两个：一键求助 + 服务预约。功能越少，使用率越高。

所以老人端（H5）我只保留三个页面：

• 首页大按钮：一键呼援（拨打紧急电话并推送定位给家属）
• 服务预约：选择服务类型（图标+大字），选择时间段，确认
• 我的订单：查看订单状态，大字显示“已完成/进行中”

字号统一设置18px以上，按钮高度不低于48px，所有确认弹窗用大按钮+高对比色。

这里有个细节：很多老人不会拼音输入，所以服务预约里的地址尽量直接带出档案里的默认地址，允许家属端代修改。不要让老人在H5上手动输地址。

4.3 前后端联调与跨域处理

Vue开发环境我用Vite代理（Vue2用vue.config.js），生产环境把前端dist打包放到SpringBoot的static目录下。这样简单粗暴，不需要额外部署Nginx。跨域问题主要出现在开发环境，我用的配置如下：

// vue.config.js module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }

后端这边统一在配置类里把跨域处理和拦截器注册好。顺序很重要：先跨域过滤器，再登录拦截器，否则预检请求直接会被拦截掉。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/api/login", "/api/captcha", "/error"); } @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } @Bean public LoginInterceptor loginInterceptor() { return new LoginInterceptor(); } }

一个容易踩的坑：allowCredentials(true) 和 allowedOriginPatterns("*") 在SpringBoot新版里必须配合使用，否则浏览器报错说ACAO和ACAC冲突。这个不踩一次很难记住。

5. 五大核心模块实现详解：健康预警、工单流转、费用结算、报表统计与消息推送

5.1 工单流转完整链路

工单的生命周期是：家属或老人在线预约 -> 管理员审核待派 -> 派给服务人员 -> 服务人员接单/开始服务 -> 上传服务完成记录 -> 管理员确认完成 -> 生成结算单 -> 家属在线支付 -> 家属评价。

这8个步骤里最容易出问题的是“管理员确认完成”这个节点。因为服务人员上传的记录需要照片佐证，如果照片缺失，管理员应打回重传而不是直接完成。这个逻辑我建议做在接口层面：

public void confirmComplete(Long orderId, Long operatorId) { ServiceOrder order = orderMapper.selectById(orderId); if (order.getStatus() != ORDER_STATUS_SERVICING) { throw new BusinessException("订单状态异常"); } // 校验是否有服务照片 List<String> photos = servicePhotoMapper.selectByOrderId(orderId); if (CollectionUtils.isEmpty(photos)) { throw new BusinessException("请至少上传一张服务完成照片"); } // 生成结算记录 settleService.generateSettleOrder(order); // 状态流转 orderStatusHandler.handle(orderId, ORDER_STATUS_SERVICING, ACTION_CONFIRM_COMPLETE); }

5.2 健康预警闭环

这个模块我放在高优先级，因为它是区分“养老管理系统”和“记账软件”的关键。

健康预警不是只生成一条记录，而是要有一个完整流程：自动或者人工录入健康数据 -> 引擎判断异常 -> 生成预警记录 -> 推送给家属和管理员 -> 家属标记“已关注”或“处理完成” -> 记录处理结果。

我建了两张表：health_alert（预警主表）和health_alert_handle（处理记录表）。字段包括老人ID、异常项目、阈值值域、实际测量值、预警级别（1一般/2紧急）、状态（0待处理/1处理中/2已处理）、处理人备注等。

后端判断逻辑我用的是策略模式，每种指标一个判断器：

public interface AlertRule { boolean isExceeded(HealthRecord record, ThresholdConfig config); String getItemName(); }

比如血压判断：

@Component public class BloodPressureRule implements AlertRule { @Override public boolean isExceeded(HealthRecord record, ThresholdConfig config) { return record.getBloodPressureHigh() > config.getBpHigh() || record.getBloodPressureLow() < config.getBpLow(); } }

这样要加指标（比如血氧），新增实现类即可，不用改动核心逻辑。

5.3 费用结算与服务定价

养老服务要支持按次收费、按月套餐、单项服务优惠价、政府补贴折减等模式。我做了张service_price_config表，按服务类型+老人类型（低保/普通）区分价格，以及一张settle_order表。

计算逻辑注意精度问题：所有金额计算用BigDecimal，四舍五入到分。补贴折减优先级是：政府补贴 > 优惠券 > 会员折扣，这个顺序别搞错了。

5.4 数据报表统计

后台首页的“月度服务报表”是管理员的刚需。我用MyBatis写SQL做聚合统计，比如“各服务类型本月完成单量”：

<select id="selectMonthlySummary" resultType="map"> SELECT service_type, COUNT(*) AS orderCount, SUM(IF(status = 3, 1, 0)) AS completedCount, ROUND(SUM(IF(status = 3, order_amount, 0)), 2) AS completedAmount FROM service_order WHERE created_time >= #{startTime} AND created_time &lt;= #{endTime} GROUP BY service_type </select>

注意IF(A=B,1,0)在MySQL里的写法，以及<这种在XML里的转义，这是MyBatis刚入手最容易报错的两个地方。

5.5 消息推送与通知中心

系统要有站内信+短信两个通道。站内信走表sys_notification，短信模块我预留了接口（接第三方短信服务），本地测试用log代替。

public interface SmsSender { void send(String phone, String content); }

老人端一有重要通知（健康预警、工单确认成功），站内信马上推送；紧急健康预警走短信+语音呼叫，这两者级别不同，要分开处理。

6. MyBatis踩坑实录：动态SQL、分页插件与Mapper参数传递

6.1 动态SQL的优雅写法

养老服务平台的列表查询条件非常多，老人档案列表要按姓名、年龄区间、慢病类型、风险等级、社区筛选。这种场景正是MyBatis动态SQL的用武之地：

<select id="selectElderPage" resultType="com.demo.eldercare.entity.ElderInfo"> SELECT * FROM elder_info <where> <if test="name != null and name != ''"> AND name LIKE CONCAT('%', #{name}, '%') </if> <if test="minAge != null"> AND age >= #{minAge} </if> <if test="maxAge != null"> AND age &lt;= #{maxAge} </if> <if test="riskLevel != null"> AND health_risk_level = #{riskLevel} </if> <if test="communityId != null"> AND community_id = #{communityId} </if> </where> ORDER BY created_time DESC </select>

<where>标签会自动去掉第一个多余的AND，这个比手动加WHERE 1=1干净多了。但要注意一个问题：如果查询条件里没有非空字段，<where>会生成空WHERE，然后整个SQL变成SELECT * FROM elder_info ORDER BY ...，这是没问题的。

6.2 分页插件PageHelper的痛与解

PageHelper我用过很久，但必须说它有两个坑：

第一个坑：分页参数和查询逻辑耦合。PageHelper是基于ThreadLocal的，如果代码里先执行了一次其他查询（比如count）再调用分页查询，线程里残留的分页参数会导致第二个查询被意外分页。

第二个坑：排序和聚合查询容易翻车。PageHelper自动改写的SQL在遇到GROUP BY或者子查询时，经常会多包一层导致性能下降。

我个人的建议是：单表查询可以用PageHelper，一旦涉及多表关联或复杂统计，直接手写LIMIT #{offset}, #{pageSize}，配合MySQL的COUNT(*) OVER()窗口函数拿总数。牺牲一点开发效率，但排错的时候能少掉很多头发。

6.3 Mapper参数传递的规范

如果一个Mapper方法有多个参数，一定要用@Param注解，不要传实体对象然后再在里面取。原因很简单：防止字段名拼写错误在编译期才发现不了。

@Mapper public interface ServiceOrderMapper { List<ServiceOrder> selectByCondition(@Param("elderId") Long elderId, @Param("status") Integer status, @Param("startDate") String startDate, @Param("endDate") String endDate); }

XML里直接用#{elderId}，不用前缀。规范的情况下，XML和Java文件放同包，编译期就能校验，这是MyBatis的最佳实践。

7. 从零跑通这个项目：环境配置、初始化数据与部署验证

7.1 本地环境准备

需要注意：SpringBoot版本不要太新，如果用的2.7系列配JDK17可能有兼容性问题。这个项目我用的是SpringBoot 2.3.12.RELEASE，搭配JDK8，稳定得很。很多人拿到新项目习惯性用最新的SpringBoot版本，结果一堆兼容性报错，真没必要。

7.2 数据库初始化

数据库命名我用eldercare_db，建库语句：

CREATE DATABASE IF NOT EXISTS eldercare_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

注意charset必须用utf8mb4而不要用utf8，原因是因为utf8在MySQL里最多存3字节，emoji和生僻字（比如老人名字里的“𠅤”）存不进去。这个坑我帮人排查过很多次，问就是插入报“Incorrect string value”。

初始数据里至少要有：1个管理员账号（admin/admin123）、1个示例老人档案、1个服务人员账号、若干服务类型配置。

7.3 运行步骤

1. 后端：IDEA打开pom.xml，等Maven下载依赖，配好application.yml里的数据库账号密码，运行ElderCareApplication.java。前端：npm install->npm run dev，默认8081端口。

2. 用admin登录后台，先去“系统配置”里把健康预警阈值、工单超时时间配好。这里我多说一句：大部分系统上线后预警不准，大概率不是代码bug，而是阈值没配置。默认阈值来自通用医学标准，应用到具体社区必须经过本地医护人员确认再调整。你可以在“配置说明”里写清楚每个参数的含义和建议值。

3. 跑通第一个闭环：创建一个服务预约工单 -> 管理员审核派单 -> 服务人员接单开始服务 -> 上传完成记录 -> 管理员确认完成 -> 生成结算单 -> 家属支付 -> 评价。这个链路走完，项目基本就通了。

7.4 部署时最容易踩的几个坑

部署到云服务器时，我有几次被搞到凌晨两三点的经历，总结一下：

第一个坑：MySQL时区错乱。连接串必须加serverTimezone=Asia/Shanghai，否则查出来的时间比实际慢13小时或8小时。

jdbc:mysql://localhost:3306/eldercare_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

第二个坑：Linux下MySQL 8.0的认证插件。MySQL 8.0默认的caching_sha2_password认证插件，JDBC 8.0版本以下驱动不兼容。要么把驱动升级到8.0+，要么在MySQL里改成mysql_native_password。

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';

第三个坑：前后端打包部署。后端打成jar包，前端npm run build后把dist目录里的文件复制到SpringBoot的src/main/resources/static下，再重新打jar包。否则你访问http://ip:8080会看到空白页或404。

8. 扩展与进阶思路（适合毕设答辩或工作落地前加分）

养老服务平台这类项目，做完基础功能只是及格，想加分其实有非常明确的进阶方向：

第一个是中间表的设计思路。很多相似系统都栽在“扩展一个业务就要改表结构”上。我在设计时把EAV模式引入了服务表单：service_form_config存字段定义，service_form_data存值。这样加一个“上门理发备注”字段，后端和DBA都不用动，运营在后台配一下就行。雇主看到这种设计会觉得你有架构意识。

第二个是多端消息实时推送。工单状态变更后，家属端、服务人员端要实时感知。我这里没上WebSocket全家桶，而是用SSE（Server-Sent Events），代码量小、稳定、浏览器原生支持。后台状态一变，前端那个事件监听自动刷新数据，体验不输WebSocket太多。

第三个是数据权限的精细化。一个平台如果要服务多个社区，管理员不能看到所有社区的数据。我在community字段的过滤上做了一个DataScope注解，实现行级权限：默认只能查本社区数据，跨社区需要超级管理员单独授权。这个点如果能在毕设里体现出来，答辩的时候绝对加分。

第四个是一键呼援流程的闭环。老人按下SOS求助后，不只是发个短信就完事，要有一个流程：生成紧急事件 -> 推送给社区值班员 -> 值班员电话回访 -> 确认安全后关闭事件 -> 生成SOS记录归档。这个流程如果没接好，一键呼援就是个摆设。

养老智慧服务平台这类系统，表面看是软件工程，内核是对老年人真实生活场景的理解。老年人不会用复杂操作，家属在乎的是“我和父母之间有没有一条可靠的链路”，社区管理者在乎的是“服务有没有被真正完成、数据能不能支撑决策”。这些业务洞察比技术栈本身更值得花时间。你在开发时如果能把工单状态机、健康预警闭环、数据权限控制这几个模块吃透，不只是能交差，是真正能撑起一个可用系统的。这套技术选型总体是合适的——SpringBoot写后端业务、MyBatis管复杂SQL、Vue做前后端分离、MySQL存全部核心数据，中小体量的智慧养老项目完全够用，而且后续想接硬件设备上传健康数据、或者扩展家属端App时，结构上也留得住弹性。