企业官网建设流程全解析

最近帮一位同学看毕设项目，他选的题目是“SpringBoot+Vue 大健康养老公寓管理系统”，技术栈就是标题里的 Java+MySQL。聊天时我问他为什么选这个题，他说一方面是对养老信息化这个方向感兴趣，另一方面是这套组合在毕业设计里属于“不出错”的稳妥方案。断断续续陪他把项目从原型调到答辩通过，前后经历了不少坑，也顺手总结出一套可以复用的搭建思路。如果你也在准备类似选题，或者正在为课设找一个业务完整、有故事可讲的管理系统，这篇文章应该能帮你省下不少时间。

1. 养老公寓管理系统在管什么：核心业务与模块边界

1.1 老人全生命周期档案：从入住到退住的记录闭环

很多同学一拿到“养老管理系统”这个题目，第一反应就是做几个增删改查页面：老人列表加个表单，点保存完事。但这种做法在答辩时会非常吃亏，因为评委想看的是你理解不理解业务，而不是你会不会写 CRUD。

养老公寓里的老人档案，和普通客户管理系统的客户档案有很大区别。它更像一条从入住评估开始、到日常照护、再到退住结算结束的完整链条。

入住环节需要记录的不只是姓名身份证，还包括紧急联系人、既往病史、过敏药物、自理能力评估结果。这些字段不是摆设，后面所有护理任务、健康监测、费用计算都会引用它们。举个简单的例子：一位老人档案里标记了“糖尿病史”，护士排班时就会自动关注血糖测量任务是否覆盖到位；老人如果对某种药物过敏，医嘱开药时系统必须弹出提醒，否则一旦出了问题就是事故级别的失误。

我在项目里把老人档案模块拆成了四个子块：基本信息、入住信息、健康档案、退住信息。基本信息管身份与联系人，入住信息管床位与合同周期，健康档案管病史、过敏史和家属备注，退住信息则保留退住原因和费用结算记录。这样拆分之后，前后端页面的职责都很清楚，数据库表也不容易越改越乱。

1.2 健康数据与护理任务的联动逻辑

“大健康”这个词听着高级，落到实处其实就是两件事：每天采集到哪些健康数据，这些数据能不能触发对应的护理动作。

在养老公寓场景下，健康数据主要来自两类设备：一类是老人随身佩戴的智能手环，一类是护士每日巡房用的血压计、血糖仪、体脂秤。手环数据可以定时同步到系统，生成心率、步数、睡眠时长的趋势曲线；巡房数据则需要护士手动录入，或者通过蓝牙一体机导入。

健康数据如果不和任务联动，那它只是一堆躺在数据库里的数字，对实际运营没有任何价值。所以我在这套系统里设计了规则引擎的思路：当某位老人的血压连续三天高于阈值时，系统自动生成一条“重点关注”标记，并推送给负责该床位的护理人员；当血糖记录异常时，系统提醒护士安排复测，同时通知家属。闸值设置不要写死在代码里，最好做成公寓管理员可以在后台自行调整的配置项。这样操作起来灵活，写论文的时候也有“参数可配置”的亮点可以讲。

1.3 费用、床位与家属沟通：业务完整度的加分项

只做老人档案和健康管理，系统会显得单薄。真正让项目饱满起来的，是费用管理、床位管理、家属沟通这三个模块。

费用管理在养老公寓里还是比较复杂的：月费、护理费、餐费、空调费、临时加项费，还有押金和退费。如果只做一张简单的账单表，很快就会发现实际业务根本对不上。我建议把账单拆成“应收明细”和“缴费记录”两张表，应收明细按周期自动生成，缴费记录则对应每一笔实收。再配合一个简单的统计报表，展示公寓当月入住率、应收总额、实收总额和欠费名单，这就形成了一个完整闭环。

床位管理看起来只是一个状态字段，但做的时候要注意状态流转。空置、已入住、预留、维修、保洁中，这几者之间不是随意切换的。比如床位处于保洁中就不能办理入住，在预约状态下也不能被其他入住申请占用。这种状态机的细节，就是代码之外的业务功力。

家属沟通模块可以做成一个轻量级的“家属留言板”，老人家属登录后能看到最近两周的健康记录摘要，也可以查看费用账单。这不复杂，却能让系统在演示时多一个角色视角，也让“多方协同”有了着落。

2. 为什么要用 SpringBoot + Vue + MySQL：选型思路与实践边界

2.1 组合优势与技术分工

聊完业务，回到技术选型。SpringBoot + Vue + MySQL 这个组合被用在这么多毕设和课设里，不是没有道理的。

SpringBoot 解决了 Java Web 开发里最繁琐的配置问题。以前用 SSM 做项目，光配置文件就要写一大堆，SpringBoot 用自动配置把大部分工作替代掉了，能让你把精力放在业务代码上。同时，Java 生态里做权限、做分页、做报表都有非常成熟的工具库，遇到问题搜索引擎一抓一大把，学习成本相对可控。

Vue 这边的核心优势是组件化和响应式开发。管理后台页面长得都差不多，无非是表格、表单、弹窗、图表。用 Vue 的组件机制把这些拆开，一个页面就是若干个组件的组合。再加上 Element 这类 UI 库，前端的开发速度和后期调整效率都很高。

MySQL 就不用多说了，轻量、稳定、好装，学习资料多。对课设级别的数据量来说，单库单表的设计完全够用，没必要上微服务，也不必引入复杂的中间件。做课程设计最重要的是能够自洽地解释自己的选择，过度设计反而会让评委质疑你是否真的理解系统边界。

2.2 数据库设计：七张核心表的结构与字段理由

很多同学喜欢一上来就打开设计工具画十几张表，结果画到最后表与表之间关系混乱。我建议从核心业务流程反推表结构：先确认系统里有几种角色，每个角色要完成哪些操作，再据此定表。

以这套养老公寓系统为例，最少需要这七张核心表：

关于字段设计，我想分享几个实操心得。第一，老人姓名、联系人和护理人员姓名最好都冗余存放在业务表里，这样列表展示时不需要反复关联查询，性能更好。第二，金额字段一律用 Decimal，不要用 Float，否则累计统计时会出精度问题。第三，健康记录的 record_type 要单独维护一套字典，比如“血压”“心率”“血糖”，在代码里用枚举或常量类统一管理，避免各处写死字符串。

2.3 哪些功能不该塞进系统：防止毕设过度设计

确定技术栈之后，还有个特别容易被忽略的问题：边界。

我见过不少同学想展现能力，往系统里塞智能推荐、语音交互、人脸识别，甚至还有想用区块链存病历的。不能说这些方向不好，但对毕设来说，盲目堆新技术会带来两个后果：一是核心业务没做扎实，答辩时被问到业务流程就支支吾吾；二是项目体积越来越大，后期改不动，bug 又多。

正确的做法是把“必需功能”和“可选亮点”分开。必需功能指的是老人档案、入住登记、健康记录、护理任务、费用账单、登录权限这六项，先把这些做成完整闭环。可选亮点在主体完成后有余力再加，比如图表统计、数据导出、消息通知。项目做到什么程度，心里要有数。核心闭环完成度 100%，比十个半成品模块漂亮得多。

3. 后端接口从无到有：分层规范、统一返回与权限设计

3.1 工程分层与关键依赖配置

后端工程我建议按经典的四层结构来写：Controller、Service、Mapper、Entity。有些同学喜欢把业务逻辑直接写在 Controller 里，页面调通是没有问题，但后期维护和写论文都会很痛苦。分层清晰的项目，代码读起来顺畅，老师看着也舒服。

用 Spring Initializr 创建工程时，核心依赖选这几项就够了：Spring Web、MyBatis（或 MyBatis-Plus）、MySQL Driver、Lombok。如果没有特殊要求，我倾向于用 MyBatis-Plus，因为单表 CRUD 几乎不用手写 SQL，可以把时间节省给核心业务。复杂查询再用注解或 XML 写自定义 SQL。

分层的另一个好处是方便加缓存和日志。比如查询健康趋势这种高频读取操作，你可以先在 Service 层加一层本地缓存；操作核心数据时，在 Service 层记录操作日志，不用侵入 Controller。

3.2 统一返回格式与全局异常处理

前后端分离的项目，接口返回格式如果不统一，前端处理起来会非常痛苦。我习惯定义 Result 结构，包含 code、message、data 三个字段。成功返回 200，业务校验失败返回 400，未登录返回 401，服务器异常返回 500。

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.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }

与之配套的是全局异常处理。用 @RestControllerAdvice 捕获异常，业务异常直接返回业务提示，未知异常则记日志并返回统一的“服务器开小差”。这套机制解决了两个实际痛点：第一，前端不用针对每个接口单独写错误解析；第二，数据库异常不会直接把底层错误信息暴露给用户。

3.3 登录鉴权：从 Session 到 JWT 的取舍

登录模块是每个管理系统的标配，但实现方式很影响答辩观感。

传统的 Session 方案写起来简单，但前后端分离时跨域场景下会有点麻烦。JWT 方案更贴合前后端分离的架构：后端在用户登录成功后签发一个 Token，前端把 Token 存在本地，后续请求带在请求头里，后端校验通过就放行。

为了减少重复代码，我建议写一个拦截器或过滤器统一处理 Token 校验，再配合一个自定义注解 @RequireRole，标注哪些接口需要管理员权限、哪些接口护士也能访问。

@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); // 校验 Token，解析用户信息并放入 request attribute if (token == null || !JwtUtil.verify(token)) { response.setStatus(401); return false; } return true; } }

这里有个细节值得注意：角色权限不止是控制“能不能进系统”，还要控制“能看哪些数据”。护士登录后不应该看到财务统计，管理员也不应该一一查看护理明细。做权限控制时，不光在菜单栏隐藏，接口层面也要拦截，否则就是“前端藏按钮、后端裸奔”。

3.4 核心业务接口的代码演示

列举两个比较有代表性的接口，方便大家理解设计思路。

第一个是新增老人档案并分配床位。这里涉及事务：老人基本信息插入成功后，还要更新床位状态，两个操作必须同时成功或同时失败。用 @Transactional 注解就能实现。

@Transactional(rollbackFor = Exception.class) public Long addElder(ElderAddRequest request) { ElderInfo elder = new ElderInfo(); BeanUtils.copyProperties(request, elder); elderMapper.insert(elder); ApartmentRoom room = roomMapper.selectById(request.getRoomId()); if (!"空置".equals(room.getStatus())) { throw new BusinessException("床位当前不可入住"); } room.setStatus("已入住"); roomMapper.updateById(room); return elder.getId(); }

第二个是健康趋势查询。这个接口常被前端图表调用，返回的数据需要按时间排序，而且一次查询要返回多条记录。在 Service 层把 Mapper 查出的原始列表按日期分组成 Map，再填充到折线图需要的结构里。

接口设计上有几条原则：列表接口不要一次性把全表数据返回，建议配合 PageHelper 或 MyBatis-Plus 的分页能力；删除操作尽量用逻辑删除而不是物理删除，养老行业的数据审计要求很高，物理删数据是会出问题的。

4. 前端页面与联调细节：Vue 管理后台的可演示性

4.1 工程初始化与路由设计

前端我用 Vue 3 + Vite + Element Plus 组合创建工程。Vite 启动速度快，Element Plus 组件全，能省去很多造轮子的时间。

路由结构建议和菜单一一对应，页面路径尽量用语义化写法。登录页是独立路由，登录成功后进入主布局，主布局内嵌套老人管理、健康管理、护理任务、费用管理、系统设置这些子路由。配合路由守卫，未登录时自动跳转到登录页。

const router = createRouter({ history: createWebHistory(), routes: [ { path: '/login', component: Login }, { path: '/', component: Layout, redirect: '/dashboard', children: [ { path: 'dashboard', component: Dashboard }, { path: 'elder', component: ElderList }, { path: 'health/:id', component: HealthRecord }, { path: 'care', component: CareTask }, { path: 'fee', component: FeeBill } ] } ] });

项目里页面一多，组件拆分就很重要。老人列表页里，搜索表单是一个组件，表格是一个组件，新增/编辑弹窗是一个组件。每个组件只干一件事，后续加字段、调样式都方便。不要一个页面堆一两千行代码，不然毕设后期改需求时会改到自己崩溃。

4.2 axios 封装与携带 Token

前后端联调的第一步，是让所有请求自动带上 Token，并且对错误响应做统一处理。我习惯在 src 目录下建一个 request.js，对 axios 做二次封装。

import axios from 'axios'; const request = axios.create({ baseURL: '/api', timeout: 10000 }); request.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = token; } return config; }); request.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { ElMessage.error(res.message); return Promise.reject(new Error(res.message)); } return res; }, error => { if (error.response && error.response.status === 401) { router.push('/login'); } else { ElMessage.error('请求失败，请稍后重试'); } return Promise.reject(error); } );

baseURL 这里有个技巧。本地开发时后端启动在 8080，前端启动在 5173，如果直接跨域请求，需要在前端配置代理转发，把以 /api 开头的请求转发到后端地址。这样做的好处是，项目部署上线时只需把 /api 改成网关地址，前端代码不用改。

4.3 页面渲染、分页与状态提示

管理后台最常见的页面模式是：顶部搜索栏、中间表格、底部翻页、右上角新增按钮。这种模式在 Element Plus 里实现成本很低，但有几个细节能拉开差距。

第一个是表格列的状态显示。比如费用账单的缴费状态，不要直接显示数字 0 和 1，用 tag 组件显示成“未缴”“已缴”，颜色也区分开。护理任务状态同理。第二个是空数据的占位提示，自定义 empty 插槽比默认的空白页更有温度。第三个是操作完毕后的 message 提示，新增成功、删除成功、保存失败，每个操作都要让用户得到反馈。

列表接口的分页参数建议统一为 pageNum 和 pageSize，后端返回 total 给前端，前端根据 total 渲染分页器。不要把 total 写死，不然翻到第二页就没数据了。

5. 从“能运行”到“答辩优秀”：毕设项目的四个打磨方向

5.1 演示数据设计要讲得出故事

很多同学答辩现场翻车，不是因为系统没做出来，而是演示数据是乱造的。数据库里随便插几条张三李四，点开表格给评委看，评委完全没感受到业务流程。演示数据要像剧本一样设计。

我建议准备这样一条完整的故事线：一位老人从入院登记开始，系统为他分配床位，录入既往病史，生成首月的费用账单；接着连续一周每天录入健康数据，某天血压偏高触发预警，系统生成重点关注提醒和护理任务；护理人员完成任务后填写执行记录，家属登录系统看到健康趋势图和费用明细，在留言板留了一句感谢；月底系统生成费用统计报表，公寓管理员可以一览应收实收情况。这套数据演示下来，系统每个关键模块都被涉及，评委听完基本就知道你这套项目是完整跑通的。

5.2 用图表把“大健康”可视化

养老公寓系统想突出“大健康”三个字，最简单的办法是让数据可视化。健康监测数据做成折线趋势图，比一堆文本记录直观得多。ECharts 是最常用的方案，通过 npm 安装后按需引入组件，把后端返回的数据稍微加工成图表需要的格式就行。

图表建议至少做两个：第一个是健康趋势图，可以切换查看心率、血压、血糖等不同指标；第二个是公寓运营概况图，包含入住率、今日护理任务完成率、本月费用收缴情况。这两个图表放在首页看板上，登录系统第一眼就有视觉冲击力，答辩演示的开场会顺利很多。

5.3 权限与操作日志是答辩加分点

如果只做了一本简单的登录判断，系统的安全性会显得很弱。我建议在答辩前加上两个看似小、但很能体现工程意识的能力：权限细分和操作日志。

权限细分指的是不同角色看到不同的菜单，后端接口也有对应控制。演示时你可以现场切换账号，一个管理员账号、一个护士账号，让评委看到护士登录后看不到财务模块。这个动作虽然简单，但很直观。

操作日志则是另一个容易被忽略的模块。谁在什么时间新增了老人档案、修改了费用记录、导出了健康数据，都应该有记录。答辩时如果评委问“系统的审计能力体现在哪里”，你就可以直接打开日志列表给他看。

5.4 论文结构与答辩话术要点

项目做得好，论文也要对得上。论文结构可以按这个顺序组织：绪论背景与意义、相关技术介绍、需求分析、系统设计、功能实现、系统测试、总结展望。其中需求分析部分要画用例图和流程图，系统设计部分要有 ER 图和架构图，功能实现部分要贴核心代码并配合截图。

答辩话术有一个原则：讲清楚“为什么这么做”比“怎么做”更重要。比如数据库表设计时为什么要冗余字段？因为列表查询性能更好。为什么要用 Redis 做缓存？因为健康趋势接口访问频率高。提前把所有选型理由准备好，评委追问时就不会慌。

6. 真实调试中踩过的坑与解决办法

6.1 MySQL 8 时区与字符集导致的凌晨报错

第一次启动项目时，控制台报了时区相关的异常，连接数据库失败。查看日志发现是 MySQL 8 默认使用 UTC 时区，而本地系统是东八区，两者对不上。

解决办法有三步：第一步，在数据库连接串上显式加上 serverTimezone=Asia/Shanghai 和 characterEncoding=utf8；第二步，在 MySQL 初始化时指定字符集为 utf8mb4，避免插入生僻字或 emoji 时乱码；第三步，确认数据库表本身是 utf8mb4 编码，老库迁移时特别容易在这上面吃亏。

6.2 前端跨域配置：为什么 Post 请求会变成 Options

前后端分离联调时，前端某个新增接口一直请求失败。打开浏览器开发者工具，发现接口请求的方法是 OPTIONS，而不是 POST。这就是典型的跨域预检请求问题。

当请求包含自定义请求头（比如 Authorization）或 Content-Type 为 application/json 时，浏览器会先发送一次 OPTIONS 预检请求，询问服务器允许哪些来源、哪些请求头。后端如果用拦截器做权限校验，很可能把这次预检请求拦截掉，导致后续真正的 POST 请求无法发出。解决办法是在拦截器里放行 OPTIONS 请求，再通过 CorsFilter 合理配置跨域规则。或者更简单，前端通过 Vite 把 /api 代理到后端，浏览器从头到尾只访问同一个源，就不会有跨域问题。

6.3 日期时间序列化：后台时间比前端少 8 小时

健康记录列表里，每条记录的采集时间都比实际少了 8 小时。原因是后端把 Date 对象通过 JSON 序列化给前端时，默认按 UTC 时区处理了。

解决方式是在 application.yml 里统一配置 Jackson 的日期格式和时区：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这个坑很隐蔽，不仔细比对时间根本发现不了。建议在项目一开始就做几个接口测试，专门检查返回的日期时间是否和预期一致，别等到答辩前一天才手忙脚乱。

6.4 刷新页面 404 与图片上传大小限制

前端路由用 history 模式时，本地开发没问题，但打包部署到服务器后，刷新非首页路由会返回 404。原因是服务器没有把所有路由都指向 index.html，后端需要配置一个 fallback 规则。用 SpringBoot 部署时，可以写一个控制器把所有非接口路径转发到 index.html；用 Nginx 部署时，配置 try_files 即可解决。

图片上传这个坑也很常见。默认 SpringBoot 的文件上传最大是 1MB，养老公寓系统上传老人证件照片时，手机拍的照片轻松超过 2MB。需要在配置里把 spring.servlet.multipart.max-file-size 和 max-request-size 调大，同时在前端做好文件类型和大小的校验，避免无效请求打到底层。

这个项目做下来，我最大的感受是：养老公寓管理系统不像某些前沿技术项目那样“炫”，但它对业务完整度的要求很高，对工程习惯的锻炼很实在。从表结构设计到接口规范，从角色权限到数据可视化，每一步都有值得琢磨的地方。如果你准备选它做毕设或课设，核心思路就是把业务流程吃透，然后用一套简洁清晰的技术栈把流程跑通，再花时间打磨好演示数据和答辩话术。做到这几点，这套项目一定能成为一份拿得出手的作业。