企业官网建设流程全解析

1. 这个毕设题目为什么值得做：社区养老背后的真实痛点

如果你正在准备计算机毕设，又在选题列表里看到了“安康市社区老人管理系统”“基于SpringBoot的社区长者健康照护平台”这类题目，先别急着把它当成一个普通的增删改查项目来写。这个题目我去年完整做过一版，从 SpringBoot 后端到 Vue 前端，再到数据库设计和部署答辩，全部走了一遍。今天把设计思路、技术选型理由、核心功能拆解和踩坑记录都整理出来，给准备做“银发人群智慧社区服务系统”或类似题目的同学一个真实参考。

这类题目看起来简单，但真正做起来会发现它不是一个“老人信息登记表”的电子化，而是一套需要支撑社区日常照护服务的业务系统。社区里老年人数量逐年增加，纸质档案容易丢、信息更新不及时，社工上门服务得靠微信电话来回沟通，老人健康指标分散在体检单、家庭医生记录和子女的只言片语里。社区工作人员最需要的不是“录入信息”，而是知道哪些老人需要重点关注、今天的服务工单有没有人处理、上个月健康异常的老人有没有被跟进。把这些需求转换成系统功能，才是这个题目的核心价值。

1.1 社区场景下到底谁在用这个系统

很多人做毕设时容易陷入“我是管理员，我能全都能看”的思维，但真实社区里角色是分层的：

• 社区网格员和社工：日常走访记录、健康指标采集、接收工单、填写服务回执
• 家属：查看老人的健康动态、接收预警提醒、对服务进行评价
• 老年人本人：能用最简单的界面发起求助或查看基本信息
• 系统管理员：维护人员权限、配置数据字典、查看统计报表

我在设计时一开始只做了管理员和普通用户两个角色，后来被指导老师问了一句“社工和家属看到的东西能一样吗？”才意识到，角色权限才是这类系统的题眼。不同角色看到的数据范围、能执行的操作完全不同，这也是答辩时最容易被追问的地方。

1.2 题目里三个关键词：安康市、社区、老人

“安康市”是地名，可以直接替换成任何一个城市，本质是“属地化管理”；“社区”决定了系统的边界，不是大型医院，也不是全市级平台，而是以社区网格为单位；“老人”决定了交互方式和数据维度，相比年轻人，老人数据更需要亲属参与和线下服务配合。

我最后把系统名称定为“社区长者健康照护平台”，因为“照护”比“管理”更贴合业务。系统里不只有老人档案的增删改查，还有健康指标记录、照护计划、服务工单和预警推送，这才是题目里“银发人群智慧社区服务”的真实含义。

1.3 和普通“老人信息管理系统”的本质区别

普通系统维护的是静态属性：姓名、身份证号、地址、电话。但这个题目里藏着动态业务：老人今天的血压是否异常？上周安排的定期回访有没有完成？家属是否在系统上看到了预警？这些问题需要工单流转、健康记录和通知机制来回答。

所以我在功能设计时定了一条主线：一切功能都围绕“发现需求 - 创建工单 - 执行服务 - 反馈结果 - 家属确认”这条闭环展开。健康记录和走访记录是输入，工单是流转载体，统计报表是输出。只要这条闭环成立，系统就算立住了。

2. 为什么选SpringBoot + Vue前后端分离：选型背后的真实理由

技术选型不能只写“因为流行”，答辩老师会追问原因。我当时的方案是后端 SpringBoot + MyBatis Plus + MySQL，前端 Vue + Element UI，再用 JWT 做认证。整个组合跑下来非常稳，下面把每个选择背后的思考说清楚。

2.1 SpringBoot在毕设场景下的优势

对比传统 SSM 结构，SpringBoot 最大的价值是“去配置化”。以前搭 SSM 需要写一堆 XML 配置文件，很多同学在配置数据源和事务的时候就已经崩溃了。SpringBoot 通过自动配置和内嵌 Tomcat，让项目能快速启动，代码结构也清晰。

对社区老人管理系统这类业务，没有高并发，没有复杂分布式需求，核心是快速把业务逻辑做好。SpringBoot 自带starter机制，想加什么依赖直接加，非常适合毕设这种需要在有限时间内交东西的场景。

我建议使用 SpringBoot 2.7.x 版本配合 Java 1.8，而不是一上来就追 SpringBoot 3 和 Java 17。很多教程和依赖包对旧版本更友好，毕设追求的是稳定，不是踩新版本的坑。这个建议在热词里也出现过“springboot版本太高”相关问题，足以说明版本选不好会卡一整天。

2.2 前后端分离到底“分离”了什么

很多同学的毕设题目里自带“前后端分离”这几个字，但答辩时需要回答清楚：分离的不是“前端代码和后端代码放不同文件夹”，而是“前端不再依赖后端生成页面，后端只提供数据接口”。

传统 JSP 模式是后端用模板引擎渲染 HTML，前后端代码耦合在同一个工程里。前后端分离后，Vue 负责页面路由、数据绑定和交互，SpringBoot 只返回 JSON 数据。这样有几个实际好处：

• 前端开发和后端开发可以并行，接口定好后各做各的
• 换一套前端界面不用动后端逻辑
• 部署时可以分别使用Nginx和Java服务，扩展性好

我在项目里做到了“后端接口返回数据，前端页面上渲染”，没有直接返回过带 HTML 的页面，答辩时老师一眼就能看懂这是真正的前后端分离。

2.3 为什么我没有直接套若依框架

做 Java 毕设的人很难绕开若依这类脚手架，它自带了用户管理、权限管理、代码生成器，确实省时间。但我最后选择从零搭建，有两个原因：

第一，若依整合了大量代码，很多逻辑不是自己写的，答辩时若追问某个权限拦截器或数据权限是怎么实现的，很难答清楚。第二，这个题目并不复杂，自己搭建一套轻量级的权限方案反而更容易掌控。用 SpringBoot + JWT + HandlerInterceptor 做一套简单的登录拦截，代码量不大，但能讲清楚每个环节。

当然，如果时间真的来不及，用若依二次开发也能过关，只是你需要额外花时间理解它的权限体系，否则项目成了“框架作品”而不是“你的作品”。

2.4 整体技术栈清单

这里特别注意，Vue 2 和 Element UI 的老搭档非常成熟，对毕设来说不容易出错。如果你熟悉 Vue 3 + Element Plus 也可以，但我当时为了少踩坑选了 Vue 2，后期证明这是个明智决定。

3. 核心功能拆解：从老人档案到健康照护闭环

这个系统的功能点很多，但真正决定系统价值的只有几个核心模块。我按业务优先级把它们串起来，你会发现每个功能都不是孤立的。

3.1 老人档案管理里的“不见于论文”的细节

老人基本档案谁都写，难的是字段设计。我最初的表只有姓名、性别、年龄、住址、电话，做完发现根本不够用。后来根据社区实际业务补充了这些关键字段：

• 身份证号：保存时做脱敏处理，只展示前3位和后4位，中间用星号代替
• 出生日期：由身份证自动提取，年龄用当前日期计算，而不是手工填年龄字段
• 紧急联系人：至少一位，用于健康预警时短信通知
• 健康标签：高血压、糖尿病、独居、失能、轻度认知障碍等，多个标签在列表页用不同颜色Tag展示
• 网格区域编码：这个字段非常关键，后面做按片区的统计报表全靠它

列表页做了等级色块：高风险老人显示红色，中风险橙色，普通绿色。这样社工一打开页面就知道今天优先回访谁。这些设计虽然不复杂，但体现了对业务场景的理解。

3.2 健康照护计划与工单流转：让服务“闭环”

照护计划是“预定的服务”，比如每周给独居老人上门量血压一次、每月电话慰问两次。工单是“实际执行的服务”，由计划生成，也可以是临时发起的求助。

我设计了这样的工单状态流转：

• 待受理：管理员/家属创建，等待社工接单
• 执行中：社工接单并上门
• 已完成：社工填写回执
• 已评价：老人或家属对服务打分

关键点在于：工单一旦创建，它就应该出现在接单人列表里，并且状态变化要记录时间线，方便查看每个环节耗时。我还给工单增加了优先级字段，普通、紧急、特急。特急工单自动向管理员发送站内通知，保证不会被遗漏。

3.3 三端一屏：家属端、社工端、管理端怎么设计

系统不是单一人群使用，我按角色拆了三个前端入口：

三端共用同一个后端，通过角色权限控制接口访问范围。家属端我特意放大了字号，按钮做得很大，因为实际使用的可能是老人的子女，甚至是老人本人。这个细节很加分，答辩时老师会觉得你考虑到了用户体验。

3.4 健康数据预警与提醒模块的设计思路

健康资料不能只存不看。我在 health_record 表里记录了血压、血糖、心率、血氧等指标，并设置了预警规则：

• 血压高压超过160或低于90触发预警
• 血糖空腹高于7.0mmol/L触发预警
• 心率高于100或低于60触发预警
• 同一指标连续两次异常时，自动生成一条提醒记录

预警消息推送给家属和网格员。实现方式不复杂：后端定时任务每小时扫描一次当天数据，命中规则后插入 alert_record 表，并通过 WebSocket 主动推送到在线前端。这样家属端可以看到“今天血压偏高”的提醒，社工端会自动生成回访任务。

3.5 一个完整的用户故事：从“老人求助”到“工单闭环”

我拿一个场景来说明系统怎么串起来：一位老人早上感到头晕，家属在外地，先在家属端点击“求助”按钮，填写“老人摔倒需要帮助”。管理员收到特急工单，立刻分配给离老人最近的社工。社工接单上门，测了血压，填写了回执：“血压190/110，已陪同至社区医院。”老人子女登录家属端看到回执和血压记录，点了确认，并对服务进行了评价。整个过程在系统里留下了完整轨迹。

这个用户故事我没有写到论文里，但在答辩时讲出来非常有效。它证明系统不是摆样子的，而是能真实承载业务流程的。

4. 数据库表设计：这些表和字段是踩坑后确定的

数据库设计决定了系统的上限。我一开始只建了老人表和用户表，后来随着业务扩展，表结构改了三次。下面是最终用起来很顺的核心表结构。

4.1 核心表关系

我用文字梳理一下核心表的关系：

• 用户表 sys_user：统一保存管理员、社工、家属的登录账号，通过 role 字段区分
• 老人表 elder：保存老人基本信息、健康标签、网格区域
• 家属关系表 elder_family：老人与家属的多对多关系
• 照护计划表 care_plan：记录服务类型、周期、下次执行时间
• 服务工单表 service_order：记录工单类型、状态、优先级、指派人和回执内容
• 健康记录表 health_record：记录老人每次健康指标数据
• 走访记录表 visit_record：社工走访时填写的现场情况
• 预警记录表 alert_record：触发预警规则后生成的提醒

老人和家属之间通过关系表关联，而不是在老人表里直接放“家属姓名”字段，因为一个老人可能有多个家属，一个家属也可能关联多个老人。逻辑外键关联，不使用数据库物理外键，这是主流实践，也方便后续分表和迁移。

4.2 软删除和状态字段的取舍

老人、工单这类关键业务数据，我全部使用 delete_flag 做逻辑删除。原因是健康记录和工单都有审计需求，不应该被物理删除。比如一个社工误删了老人的健康档案，如果没有软删除，历史记录就全丢了。

工单状态我用 status 字段配合枚举类管理，而不是让每个状态变成单独的布尔字段。比如工单不只是 status = 已完成，还需要记录完成时间、完成人、回执内容。状态流转由后端统一控制，前端只展示状态标签。

4.3 健康指标的动态存储方案

健康指标是系统里最值得研究的数据结构。老人可能测血压、血糖、心率、血氧、体温，如果为每个指标建一个字段，表会越来越宽，扩展新指标还得改表。我采用了一种更灵活的方式：

CREATE TABLE health_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL, metric_type VARCHAR(32) NOT NULL COMMENT '指标类型：血压/血糖/心率等', metric_value VARCHAR(64) NOT NULL COMMENT '指标值，如130/85', unit VARCHAR(16) DEFAULT NULL COMMENT '单位：mmHg/mmol/L/次每分', measure_time DATETIME NOT NULL COMMENT '测量时间', operator_id BIGINT COMMENT '记录人，社工或家属', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, delete_flag TINYINT DEFAULT 0 );

这样做的好处是新增一个指标只需要在数据字典里加一个 metric_type，不用改表结构。缺点是查询一个老人的多个指标时需要行转列，或者在前端分组展示。我在 Service 层拼接返回结构，把最近一次血压、血糖等数据组装成 Map，前端展示起来就很方便。

4.4 索引与字段设计经验

有几个实际经验值得记下来：

• 年龄字段永远不要存，用出生日期计算
• 身份证号需要加密或脱敏存储，别明文展示
• 时间字段都存 datetime，不要存字符串，排序和统计都更可靠
• 金额如果出现，用 decimal 而不是 float
• 高频查询字段加索引：elder_id、status、create_time、metric_type、notification_time

我吃过一个亏：刚开始把“网格区域”忘了，结果做“各片区老人数量统计”时发现没有字段可查，只能返工补建 region_code。如果题目里带有城市、社区等关键词，这个字段一定在最初就要设计进去。

5. 前后端分离联调实战：接口约定、JWT认证与分页那些坑

写代码只是第一步，前后端联调才是真正耗时的地方。下面这些内容是真实项目里反复遇到的问题，记录下来比任何教程都有用。

5.1 统一返回结构：让前端不再“一处一换”

刚开始后端接口返回格式不统一，有的返回 List，有的返回 Map，前端 axios 拦截器没法做统一处理。后来我定了一个通用响应类：

public class Result<T> { private Integer code; private String msg; private T data; } public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMsg("success"); result.setData(data); return result; }

前端 axios 封装里统一判断 code 是否为 200，不是则弹出错误消息。这样后端只要保证接口返回 Result 结构，前端代码就非常干净。这个约定在联调第一周就确定下来，后边省了几十次扯皮。

5.2 跨域问题：开发环境最常见的一堵墙

前端跑在 8050 端口，后端跑在 8080 端口，浏览器会拦截跨域请求。解决方式有两种：要么在后端写全局 CORS 配置，要么用 Nginx 反向代理。

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

注意：生产环境如果用 Nginx 把前端静态资源和后端接口放在同一个域名下，就不需要这个配置了。我的做法是开发环境用 CORS，部署时靠 Nginx 反向代理，两边都顺利。

5.3 JWT认证：轻量而有效的权限方案

前后端分离项目没有 Session 依赖，我用 JWT 做登录令牌。登录接口校验用户密码后生成 token，前端存到 localStorage，请求时放到 Authorization 请求头。后端写一个 HandlerInterceptor 校验 token。

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { try { Claims claims = JwtUtil.parse(token.substring(7)); request.setAttribute("userId", claims.get("userId")); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; } }

这个方案比起引入 Spring Security 轻量很多，但能讲清楚认证流程。对于毕设项目中低并发的管理场景完全足够。我在前端路由守卫里做了判断：没有 token 只能访问登录页，token 过期后自动跳回登录页。

5.4 分页查询：PageHelper 和 el-pagination 的配合

分页是管理系统的标配。后端用 MyBatis Plus 的 Page 或者 PageHelper，前端用 Element UI 的表格加分页。这里有一个经典坑：PageHelper 只对紧跟着的下一句 SQL 生效。如果你在 startPage 之后又执行了其他查询，分页就会失效。

正确写法是把查询条件全部准备好，再调用分页查询：

@GetMapping("/list") public Result<Page<Elder>> list(@RequestParam Integer pageNum, @RequestParam Integer pageSize, @RequestParam String keyword) { Page<Elder> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Elder> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.hasText(keyword)) { wrapper.like(Elder::getName, keyword) .or().like(Elder::getPhone, keyword); } wrapper.eq(Elder::getDeleteFlag, 0) .orderByDesc(Elder::getCreateTime); return Result.success(elderService.page(page, wrapper)); }

前端传 pageNum 和 pageSize 即可。搜索条件尽量放在请求参数里，不要塞到 URL 路径中，这样前端维护逻辑更清晰。

5.5 联调中踩过的几个真实bug

第一个是日期格式问题。前端传到后端的时间字符串和后端返回到前端的日期格式对不上，最后靠 @JsonFormat 统一解决了：

@JsonFormat(timezone = "GMT+8", pattern = "yyyy-MM-dd HH:mm:ss") private LocalDateTime createTime;

第二个是 Long 类型 ID 精度丢失。当主键使用雪花 ID 时，Long 传到 JavaScript 会丢精度，需要转成字符串。我这里主键用了自增 ID，所以没遇到，但如果你用了 MyBatis Plus 默认雪花 ID，就要特别注意。

第三个是 Vue Router 的 history 模式部署后刷新 404。这个问题在本地开发没问题，部署到 Nginx 后刷新页面就报 404，原因是路由没有匹配到后端资源。解决办法是在 Nginx 配置里加一行：

location / { try_files $uri $uri/ /index.html; }

这三个问题都是实际开发中高频出现的，提前处理掉能让项目整体顺滑很多。

6. 部署与答辩：从本地跑通到演示不出丑

项目做完只是第一步，如何部署和演示决定了最终效果。这一部分分享我自己的实操流程。

6.1 前后端打包与部署细节

后端打包非常简单：

mvn clean package java -jar target/health-care-system.jar

前端打包：

npm run build

打包后生成 dist 文件夹，我更喜欢用 Nginx 部署，而不是把 dist 硬放到 SpringBoot 的 static 目录。因为前后端分离的意义就是要分开部署。我用一个嵌套的 Nginx 配置：

server { listen 80; server_name localhost; location / { root /home/www/health-front/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这样浏览器访问 80 端口就是前端页面，接口请求 /api/ 自动转发到后端 8080。部署完后刷新页面不会 404，跨域问题也消失了。

6.2 演示数据和演示脚本的准备

很多同学系统开发完了，一打开数据库是空的，答辩演示时现场添加数据，效果非常差。我强烈建议提前造一批演示数据：

• 老人档案不少于 10 条，覆盖独居、高血压、失能等标签
• 健康记录至少包含一组正常数据和一组异常数据
• 工单覆盖待受理、执行中、已完成、已评价四种状态
• 家属端账号已经关联好老人，打开就能看到提醒

答辩演示脚本可以按照业务故事线走：登录管理员 → 查看今日工单 → 切换到社工处理工单 → 录入一条血压异常记录 → 系统触发预警 → 家属端收到提醒并评价。整个过程大概 5 分钟，却完整展示了闭环。

6.3 答辩中我遇到的几个高频问题

把这些问题准备好，现场心里不慌：

• “为什么用 JWT 而不是 Session？” 答：前后端分离架构下，Session 依赖 Cookie 和服务器状态，JWT 无状态、可跨域、方便移动端和前端共用。
• “SpringBoot 相比 SSM 的优势？” 答：自动配置、内置容器、简化依赖管理，降低项目搭建成本，同时保留 Spring 生态的能力。
• “如果用户并发量大了怎么办？” 答：当前是低并发管理场景，后续可以通过集群部署、Redis 缓存、数据库读写分离来扩展。
• “健康数据如何保证准确？” 答：数据录入做必填校验和范围校验，测量数值超过合理范围给出提示；关键指标支持二次确认。

6.4 后续扩展：从毕设到实际可落地的智慧养老平台

如果你想让这个项目更出彩，可以加一些扩展点：对接蓝牙手环或血压计，通过定时任务把设备数据写入 health_record；引入腾讯云短信，预警时给家属发短信；把系统部署到小程序，老人子女使用更方便。

我在做这套系统时最大的体会是：不要把它当成“交差”的工具，而是当成一次完整的产品设计训练。每张表、每个状态、每次接口联调，背后都有一个真实的业务场景。只要顺着“社区里老人到底需要什么帮助”这个问题去设计，这个毕设就不会差。

最后分享一个小技巧：答辩前把所有代码 Git 提交好，写清 commit message，展示的时候可以说一句“项目全程采用 Git 进行版本管理”，这个细节往往比框架本身更能给答辩老师留下好印象。希望这篇内容能让你的安康市社区老人管理系统做得更稳、更顺。