企业官网建设流程全解析

做这种“毕设级全栈项目”，最怕的不是写不出代码，而是搞不清它到底要交付什么。标题里“源码+文档+调试+vue+前后端分离”这几个词，实际上已经把需求拆得很明白了：这是一个以演示和验收为导向的完整系统，技术栈固定，交付物固定，文档要能撑住答辩和汇报。空巢老人健康管理这个题目本身又比普通的后台管理系统多了一层业务复杂度——健康数据模型怎么设计、预警规则怎么触发、老人侧小程序怎么做得简单可用，这些都不是靠“增删改查四张表”就能糊弄过去的。

我前前后后帮人梳理过好几个类似的健康管理项目，也调试过同事新接手的小程序管理后台，今天就把这个系统的实现思路、技术选型逻辑和实际操作中涉及的坑，一条条拆开来讲。如果你正打算做这套题目，或者已经写完但还在调bug，这篇文章应该能帮你少走不少弯路。

1. 项目定位：空巢老人健康管理到底要管什么

刚开始看这个题目的人，很容易把它理解成“给管理员做几个页面，录入老人信息就算完成”。但实际上，业务方真正关注的是三件事：健康数据的持续记录与查询、异常指标的自动预警、以及家人和医护人员的及时响应。整个系统要围绕这三件事去设计，而不是围绕“用户表”去设计。

先理清角色。空巢老人健康管理系统里，使用者至少有四类：老人本人（在小程序端查看自己的健康状态、接收提醒）、家属（远程查看父母健康档案并接收预警）、医护人员（管理健康数据、给出建议）、平台管理员（维护系统与基础数据）。不同角色看到的数据范围和操作权限完全不同，所以权限模型必须从设计第一天就明确，否则后期改起来非常痛苦。

再看业务流程。健康管理的真实路径是这样的：老人（或家属）录入血压、血糖、心率、体重等指标 → 系统判断指标是否超出设定阈值 → 超出阈值则生成预警记录，并推送给家属和医护人员 → 医护人员处置后在后台记录结论 → 家属可以看到整个闭环。除此之外，空巢老人场景还有一个高频需求就是用药提醒和身体异常时的紧急求助，这些都要在功能清单里体现。

交付物的边界也要想清楚。这套系统的核心是“管理”，不是“设备接入”。如果你在标题里加入硬件设备、蓝牙血压计、IoT网关，那项目复杂度会指数级上升，而且调试环境很难复现。所以成熟的方案是把数据采集设计为手动录入+模拟数据的方式，保留一个“设备数据接入”的扩展说明即可，不真正对接硬件。这也是为什么这类项目大多采用“小程序端 + Web管理端 + SpringBoot服务端”三段式结构，而不是搞一个完整物联网平台。

简单说，项目定位决定了后面的所有设计。把“健康档案、预警闭环、家人协同、用药提醒、紧急求助”这五个关键词写进需求文档，你的项目骨架就已经立住了。

2. 架构选型：SpringBoot、小程序、Vue三者如何分工

这套系统最核心的架构决策就是“前后端分离”。微信小程序天然是一个独立前端，Vue管理后台是另一个独立前端，SpringBoot只负责提供RESTful API。很多做惯了传统单体项目的人会不自觉地想用模板引擎直接渲染后台页面，放到这个项目里是完全不适用的。

三个端的分工逻辑其实很清晰：

• SpringBoot后端：统一负责认证鉴权、健康数据管理、预警规则判断、定时任务、消息推送和文件存储。对外提供 JSON 格式的接口，不关心数据在哪个端展示。
• 微信小程序端：面向“老人/家属”的轻量入口，核心是数据录入、数据查询、预警消息接收。因为运行在微信环境里，它自带微信登录能力，不需要用户额外注册账号。
• Vue管理后台：面向“医护人员/管理员”的较重入口，核心是老人档案管理、健康趋势分析、预警处理、用药计划配置、系统设置。它运行在浏览器里，形态上更像传统管理信息系统。

技术栈方面，我建议用一套“稳妥但不老旧”的组合，既保障演示效果，又方便别人接手。后端用 SpringBoot 2.7.x + MyBatis-Plus + MySQL 5.7/8.0，权限用 JWT + 拦截器，定时任务直接上 Spring 自带的 @Scheduled，文件存储用本地目录即可；小程序端用原生小程序框架，不用引太多第三方UI库；管理后台用 Vue 2.6 + Element UI + ECharts。这个组合看起来很朴素，但恰恰是这类项目最不容易翻车的方案。

为什么不一股脑上 SpringBoot 3 + JDK 17 + Vue 3？原因很现实：很多验收环境里的 JDK 还是 1.8，面试答辩时你也不希望因为版本问题现场跑不起来。SpringBoot 2.7 对 JDK 1.8 友好，MyBatis-Plus 兼容性好，网上可查的踩坑资料最齐全，对一个以“完整能跑、逻辑清晰”为核心目标的系统来说，这就是最合理的选择。等系统稳定动起来之后，再谈升级的事也不迟。

前后端分离带来的一个直接好处是“各端可以独立替换”。比如管理后台想从 Vue 2 换成 Vue 3，只要后端接口不变，就不需要动其他端；小程序端的页面也只依赖后端 API。这种独立性在调试的时候特别舒服——我在本地启动后端服务，不改任何小程序代码就能用开发者工具联调接口；后台页面也可以用本地开发服务器直接访问，整个开发链路非常清爽。

不过分离也意味着一件事：接口文档必须提前规划好。联调阶段最容易出的问题不是代码写错，而是前端拿不到“约定好的字段”。所以做这个项目时，建议先定义好统一的接口返回结构，比如{ code, message, data }，不管成功失败都走这套格式，前端统一拦截处理。这样只维护一套数据规范，所有端都跟着走，省心得多。

3. 数据库设计：健康数据、预警规则与角色权限的落地

数据库是这类项目的承重墙。空巢老人健康管理系统里最容易踩的坑，是没有分清“基础档案”和“业务流水”。基础档案包括老人信息、家庭成员关系、用户账号；业务流水包括每一次健康测量记录、每一条预警、每一次求助事件。把流水数据往档案表里塞，后期查趋势和做报表会痛苦到怀疑人生。

先看核心表怎么拆分。用户表负责统一管理登录账号，通过role字段区分是老人、家属、医护还是管理员；老人档案表存姓名、年龄、住址、既往病史、紧急联系人；家属绑定表维护老人与家属的多对多关系；健康记录表存每一次测量数据，例如血压、心率、血糖、体重。每一条记录必须带有测量时间和测量人，因为同一个老人可能由家属代录，也可能是自己录入。

健康记录表的设计值得单独说一下。常见做法是新建一张health_record表，字段用type区分数据类型：blood_pressure、heart_rate、blood_glucose、weight，再用value字段存测量值。比如血压可以存成“收缩压/舒张压”的字符串，也可以拆成systolic和diastolic两个字段。我的建议是：把高频指标拆成专用字段，低频指标走通用字段。实际上更稳妥的做法是一张表里同时保留多个指标字段，哪条记录填了哪些字段就存哪些字段，这样查询单条详情时不用做行转列，前端渲染也好写。

预警规则可以直接用一张规则表存阈值。比如threshold表里定义指标类型、最小值、最大值、危险级别、推送对象；后端每次接收到健康记录时读取对应规则进行判断。这样做的好处是，调整报警阈值不必改代码，运营人员直接在后台改数据库或管理接口就行。千万不要把阈值写死在Java代码里，那等于给系统焊死了边界。

权限模型建议用简单但够用的RBAC。不要一上来就整 Spring Security + 动态权限表，课程设计级项目会搞得过于复杂。用一张用户表里的role字段，配合拦截器做路径级控制就足够了。比如/api/admin/**只允许医护和管理员角色访问，/api/elder/**允许绑定关系的家属角色访问。写拦截器时注意放行登录接口和健康检查接口，不然会出现“登录页面都进不去”的低级问题。

建表时统一使用create_time和update_time字段，全部走 MyBatis-Plus 的自动填充，避免在业务代码里到处写new Date()。健康记录表一定要建联合索引，索引顺序按elder_id + record_time来，否则老人健康记录量上来以后，趋势查询会越来越慢。最后，初始化 SQL 里要带上几个演示角色和演示数据，账号对应关系写在 README 里，交给验收的人第一眼能看到效果，这个细节对交付观感特别重要。

4. 后端接口与业务逻辑：预警推送、用药提醒的实现关键

接口设计遵循一个原则：接口按“业务动作”命名，而不是按“数据库表操作”命名。比如你提供的不应该是getHealthRecordList这种表结构式接口，而应该是getRecentTrend这种业务式接口。前端只关心“我要拿到最近七天的血压趋势”，不关心你底层到底查了哪几张表，这个设计意识会让前后端联调顺畅得多。

认证部分，建议用 JWT 而不是传统 Session。小程序端没有 Cookie 概念，每次请求都会在 header 里带Authorization，后端用拦截器统一解析 token。JWT 的好处是后端无状态，前端拿到后在本地存储，小程序端放在 storage 里，Web 端放在 localStorage 里。要注意 token 过期时间，小程序场景里用户可能一两周都不重新打开，过期后得能自动跳回登录页；我一般把 token 有效期设为 7 天，同时后端提供刷新接口，避免用户频繁重新授权。

健康记录的保存接口是业务核心，要把“数据入库”和“规则触发”放在同一个事务内。流程是：前端提交指标数据 → 后端校验参数 → 写入健康记录表 → 读取该老人的预警规则 → 判断指标是否越界 → 如果越界就生成预警记录并调用推送服务。这一步如果分拆成两个接口，会出现“数据已经存入但预警没生成”的脏状态，用户在演示时根本解释不清楚。整个判断逻辑用事务包裹住，要么全部成功，要么全部回滚。

预警推送到小程序，用的是微信的“订阅消息”能力。这里有一个很多人会搞混的细节：订阅消息需要用户主动授权，而且一次性订阅消息只能往用户消息列表里推一次，用户授权一次你才能发一次。所以业务设计上要在老人或家属第一次登录时引导他们订阅“健康异常提醒”和“用药提醒”，每次发送后还要提示用户再次订阅。还有一种方案是接入短信或微信公众号模板消息，但小程序订阅消息是成本最低、链路最完整的选择，适合课程设计级项目。

用药提醒用 @Scheduled 定时任务实现。每天固定时间扫描用药计划表，找到需要提醒的老人，生成提醒消息并推送。定时任务写进一个独立的RemindTask类里，不要跟服务类混在一起。跑定时任务时注意加一个简单的防重入锁，避免因为部署了多个实例导致重复提醒。虽然这类项目一般只部署单机，但好习惯还是要有的。

后端业务逻辑里最容易被忽略的，是“数据校验要有边界意识”。比如血压不可能低于 20，心率不可能高于 250，保存前要做好范围校验。小程序和后台两个前端都可能录入数据，你不能只靠前端校验，所有规则必须在后端再校验一次。还有一点，健康记录表里要记录measure_time（测量时间）和create_time（录入时间），这两个时间不是一个概念——演示的时候用户可能会手动补录前几天的数据，如果你只存录入时间，趋势图就全乱了。

5. 微信小程序端：老人侧交互与数据采集的细节处理

小程序端是这个系统里“看起来简单、实际细节最多”的部分。因为它的使用场景是小屏幕、弱网络、用户年龄偏大，所以页面设计必须坚持几个原则：文字要大、按钮要重、流程要短、反馈要明显。我不建议在小程序端做复杂的图表和表格，那是管理后台的活；小程序端真正重要的是“录入顺畅”和“提醒可见”。

页面结构上，核心是四个 tab：首页、健康记录、预警消息、我的。首页展示最近一次测量的关键指标和健康状态摘要，用大号字体显示“正常/偏高/偏低”；健康记录页提供血压、心率、血糖、体重四个录入入口，每个入口单独做成表单页；预警消息页展示历史预警列表，每条预警显示时间、指标、处理状态；我的页面里放个人信息、绑定关系、订阅消息授权入口。

小程序的网络请求建议封装成一个request.js工具文件。请求前自动在 header 里带 token，后端返回 401 时自动清理登录态并跳转登录页，返回业务错误时通过wx.showToast展示提示。封装这一层能在后面联调时省掉大量重复代码，也是展示你工程能力的一个点。不要在每个页面里写一堆wx.request，那样的代码看三天后你自己都不想碰。

登录逻辑要提前想清楚。小程序端调用wx.login拿到临时 code，传给后端，后端再用 code 调用微信接口换取 openid 和 session_key，然后生成自己的业务 token 返回。这个过程对用户是无感的，所以登录页不要做太复杂，最好就是“一键登录”按钮，点击后静默完成识别。用户初次登录时绑定老人档案，后续再进来就直接进入首页，不再重复要求登录。

表单录入是用户高频操作，必须做防错设计。比如血压录入页，收缩压输入框和舒张压输入框并排，单位默认展示 mmHg；血糖录入页默认显示“餐前/餐后”的切换选项。用户提交成功后，跳转到结果页，同时显示“已保存，指标正常/偏高”这样的反馈。不要只显示“提交成功”四个字，用户根本不知道自己的数据处于什么状态。

数据展示方面可以用ec-canvas的 ECharts 小程序版组件做简单趋势图，体重和血压最近七天的折线图足够直观。不过要注意小程序包体大小，ECharts 完整包体积不小，建议按需引入折线图和柱状图模块。如果不想引入图表库，也可以用 canvas 画一个非常简单的折线图，或者干脆用横向滚动列表展示近七次记录——对于这个使用场景，列表反而比图表更容易被老人理解。

在调试小程序时，一定要区分“开发者工具模拟”和“真机预览”两种状态。开发者工具里可以手动勾选“不校验合法域名”，但真机预览时必须在小程序后台配置 request 合法域名，否则所有请求都会失败。我见过太多人在开发者工具里调通了，一上真机就全部请求超时。打包前的域名白名单配置这一项，建议直接写进项目文档里，属于必踩必记的坑。

6. Vue管理后台：医护人员与家属的可视化管理

管理后台是整个系统的“门面”，因为答辩演示时，评委和业务方最先看的就是后台页面。Vue 部分不需要做得特别花哨，但要做到“信息密度高、操作路径短、状态展示清晰”。管理端的用户是医护人员，他们的诉求是“一眼看到哪位老人有什么异常，然后快速处理”，所以 Dashboard 的设计比功能堆砌重要得多。

后台的基础框架用 Vue 2 + Element UI 就够了，admin 布局采用左侧菜单栏 + 右侧内容区的经典结构。路由分为老人档案管理、健康记录管理、预警处理中心、用药计划管理、系统设置几个模块。登录后根据角色动态加载路由，管理员能看到全部菜单，医护只能看到健康相关菜单，这样在权限演示时比单纯隐藏按钮更有说服力。

Dashboard 页面放四个统计卡片：老人总数、今日健康记录数、待处理预警数、今日求助事件数。下面画两个图：最近七天的预警趋势折线图、各指标异常占比饼图。图表直接用 ECharts，接口返回聚合好的数据。这里有个后台开发常见的坑：不要在前端去做数据聚合，一定要让后端接口返回“已聚合”的结果，比如每天预警数量列表。前端只负责渲染，否则遇到大数据量时页面会卡到崩溃。

老人档案管理页是医护端的高频页面，列表要支持按姓名、社区、健康状态筛选，点击行进入详情。详情页需要展示老人的基础档案、近期健康趋势、历史预警记录、用药计划四个 tab。这个页面最能体现系统完整度，因为它在同一屏内打通了“老人—健康数据—预警—干预”的完整链路，答辩时照着这个页面讲业务逻辑，比讲十页 PPT 都管用。

预警处理中心是业务闭环的关键页面。列表展示所有预警记录，每条包含老人、指标、预警级别、状态（待处理/已处理）。医护点击“处理”按钮后，填写处理意见，比如“建议复查血压”“需要电话回访”，系统记录处理人和处理时间，这条预警才算关闭。项目演示到这里就是完整闭环：数据触发预警 → 医护处理 → 家属在小程序端看到处理结果。如果时间充裕，还可以在这个基础上增加简单的“回访任务”逻辑。

后台联调时最需要注意的是接口请求地址。本地开发时 Vue 项目通过代理转发请求到后端服务，比如vue.config.js里配置proxy，把/api前缀的请求都转发到http://localhost:8080。上线部署后则由 Nginx 统一做反向代理，静态页面和 API 请求都走同一个域名，这样就不会产生跨域问题。很多人在部署阶段栽跟头，就是因为在本地联调时用了http://localhost:8080直连后端，上线后忘了改配置，结果所有接口都因跨域被浏览器拦截。

后台的细节体验也很重要。列表页必须分页，表格一定要有加载状态，操作按钮要有二次确认，表单要有校验。大量使用下拉选择框的时候，初始化加载用户列表的接口要提供关键字搜索能力，不然老人数量一多，下拉框卡顿会非常明显。已经接入 ECharts 的情况下，图表容器要指定固定高度，不然初始化时拿到的高度是 0，图表就会白屏——这个问题属于“必踩一坑”。

7. 调试实战：跨域、鉴权、微信登录态这三个老大难

调试阶段是整个项目耗时最多、也最折磨人的阶段。根据我给多个类似项目做代码评审的经验，至少在三个点上你得做好心理准备。

第一个是跨域问题。前后端分离架构下，浏览器直接请求后端接口时大概率被跨域策略拦截。解决方法有几种：后端配置全局 CORS、前端开发环境通过代理转发、部署时统一走 Nginx 反向代理。最省事的做法是开发阶段后端把 CORS 全放开，前端配置代理；部署阶段用 Nginx 同域代理收起跨域请求。千万记得：开发阶段直接用fetch或axios请求后端地址时，如果发现请求status为 0 或CORS policy报错，不要怀疑代码逻辑，先检查后端是否配置了addCorsMappings。另外，带参数的 POST 请求要特别小心，需要正确处理OPTIONS预检请求，否则前端会一直报跨域失败。

第二个是鉴权链路。JWT 生成和解析本身不难，难的是各种边界情况。token 过期了前端怎么感知？后端接口异常时会不会抛 500？拦截器里对白名单路径放行是否真的生效？我调试时习惯先在后端写一个/api/auth/check接口，直接返回当前登录用户的信息，用来快速验证 token 是否正确传达到后端。如果接口通但业务接口不通，大概率是拦截器规则写得太宽，把所有/api/**都拦了，登录接口也被拦在里面了。

第三个是小程序登录态。小程序端的登录态失效跟 Web 端不一样，很多问题出在wx.login的 code 是一次性的。如果前端把 code 重复发送给后端，微信接口会返回错误。更隐蔽的问题是session_key过期后，解密用户手机号或获取用户信息时会失败。健康管理系统虽然不是重社交场景，但如果要做手机号绑定，就需要在后端维护好 openid 和用户账号的映射关系。小程序冷启动时会先检查 storage 里有没有 token，有就静默登录，没有才走wx.login流程；这个逻辑如果写反，会出现“每次打开小程序都要重新登录”的现象。

除了这三个高频问题，还有几个常见的低级坑。一是时间字段的时区问题，数据库存的create_time和前端展示的时间差八个小时，多半是 JDBC 连接串里没配serverTimezone=Asia/Shanghai。二是 JSON 序列化问题，LocalDateTime 序列化默认可能变成一串数字，需要在实体字段上统一加@JsonFormat或在全局配置里注册 JavaTimeModule。三是 MyBatis-Plus 的实体类字段名和数据库字段映射问题，驼峰命名和下划线命名不一致时，查询结果全是 null，多半是因为没开启map-underscore-to-camel-case，或者写 SQL 时没起别名。

调试这个阶段一定要养成看日志的习惯。SpringBoot 的日志默认已经挺好用，但建议把 Controller 层的入参和出参单独打一条日志，方便快速定位是前端传参错误还是后端逻辑问题。我在负责的演示项目里都会加一个简单@Aspect日志切面，统一输出请求路径、耗时和响应结果，调试效率能提升一大截。拿到一个报错先看日志，不要凭直觉猜，这个习惯能让你少掉不少头发。

8. 部署交付：源码、文档、调试一整套怎么弄

这类项目最终是要交付源码加文档的，所以“能跑”是最低要求，“能复现”是标准要求，“能讲出来”才是优秀要求。我在清理可交付项目时，会按这样的目录来组织，既方便自己维护，也方便验收的人直接上手。

根目录下放三块：backend放 SpringBoot 工程，miniprogram放小程序源码，web-admin放 Vue 管理后台。每块内部按标准项目结构排版，不要出现一堆“新建文件夹(2)”这种可怕的组织方式。根目录放一个README.md，里面写清楚环境要求、启动步骤、默认账号、目录说明和常见问题排查。这份 README 是整个交付文档的入口，花两小时写它比花两小时写功能说明都有价值。

数据库初始化脚本也特别重要。我通常用两份 SQL：一份是schema.sql只建表结构，一份是data.sql存放初始化数据。初始化数据里包含管理员账号（密码用 MD5 或 BCrypt 加密后的结果，而不是明文）、两个演示老人档案、若干条健康记录和预警记录。这样验收的人导入 SQL 后直接启动后端，不用到处找数据。没有演示数据的系统，看起来就像一个没有商品的电商网站，观感会大打折扣。

部署时推荐用最简单的模式：MySQL 装在同一台机器上，后端打成 jar 包用java -jar启动，管理后台的dist静态文件交给 Nginx，小程序通过微信开发者工具上传体验版。后端用application.yml里的spring.profiles.active区分开发和生产配置，生产环境数据库密码不要太随意。如果服务器有公网 IP，把 API 域名配置到小程序的合法域名白名单里，就可以在手机上完成体验版预览。

调试阶段的分工也要清楚。建议先把后端接口全部用 POSTMAN 或 Apifox 过一遍，确认每个接口的返回结构都符合约定。再用小程序开发者工具走一遍所有页面流程，特别关注登录、录入、预警查看三个主流程。最后再跑管理后台的主流程：登录、老人详情、预警处理。三条链路都通了，这个系统才能叫“能跑”。不要一上来就三个端同时调试，出问题时根本不知道问题出在哪一端。

文档方面要注意一个观念：文档不是给评委看“你做了什么”，而是给下一个开发者“怎么把它跑起来”。运行环境配置、版本号、启动顺序、端口占用处理、微信开发者工具设置、常见异常解决，这六项是最优先的。业务说明文档可以写简单一点，但操作文档一个步骤都不能漏。截图比长篇文字有用，特别是小程序端每个页面的截图配上简短说明，验收的人扫一眼就明白系统做到了什么程度。

最后再说一个个人感受。我处理过不少半途出问题的健康管理系统，大部分都不是代码复杂度导致的失败，而是交付前没有做“干净环境验证”：换一台没有安装任何开发环境的电脑，按 README 从零开始部署，看能不能顺利跑起来。凡是能做到这一步的项目，答辩时基本都不会翻车。把这个流程走一遍，比你多写一千行代码更有价值。