SpringBoot+Vue3+微信小程序健康管理系统开发全攻略
简介这是一套面向计算机专业学生与初学者的健康管理类全栈开发实战资源适用于课程设计、毕业设计或期末大作业场景解决健康数据记录、用户体征管理与移动端便捷访问等实际需求。资源含1284个文件涵盖139个Vue组件文件支撑前端交互逻辑、258个JS脚本含小程序业务逻辑与API调用、112个Java后端服务类基于SpringBoot构建RESTful接口、60个WXML与66个WXSS文件微信小程序视图与样式、以及关键的SQL建表脚本与配置文件整体压缩包仅9.26MB结构清晰、模块解耦度高。目前已有287人学习下载。读者可直接导入IDEA与微信开发者工具运行完整系统配套提供前后端分离架构说明、数据库初始化脚本、主流浏览器兼容性处理细节及典型报错解决方案特别适合理解Vue2与微信原生开发协同机制并为后续升级至Vue3积累工程经验。1. 项目整体架构与设计思路1.1 为什么选 SpringBoot Vue3 微信小程序这个技术组合做健康管理系统第一个要回答的问题是给谁用、谁来管、用什么形态交付。我当初定这个项目的时候需求其实很明确——用户端要够轻、够方便管理员要能看数据、做运营整个系统还要经得起后期扩展。基于这几点技术选型几乎没有什么悬念后端用 SpringBoot前端管理后台用 Vue3用户端直接上微信小程序。先说 SpringBoot。它不是最简单的框架但它是 Java 生态里综合性价比最高的选择。相比 SSM 时代的各种 XML 配置和手动整合SpringBoot 的自动配置、起步依赖、内嵌 Tomcat 这些特性能把一个后端服务的开发成本压缩到很低的程度。尤其是做这类管理系统CRUD 居多、业务规则清晰、权限模型固定SpringBoot 的 MVC 结构 MyBatis-Plus 足够覆盖 90% 的功能开发。更重要的是Java 生态的稳定性让后期维护和部署都更有保障这对于一个要交付完整源码的项目来说很关键。再讲 Vue3。管理后台那种需要大量表单、表格、弹窗、图表的场景Vue 的响应式体系和组件化模型天生就很合适。Vue3 的 Composition API 解决了 Vue2 时代逻辑复用困难的问题setup 语法写起来接近原生 JavaScript 思维状态管理配 PiniaUI 组件库用 Element Plus开发效率非常高。我实际体验下来Vue3 Vite 的启动速度和热更新体验比 Vue2 Webpack 好了一大截开发过程流畅很多。微信小程序那边就不用多说了它是目前获取 C 端用户成本最低的载体不用下载 App扫码即用对健康记录这类高频小场景非常友好。用户每天打开记录血压、血糖、体重、步数完全不需要引导安装微信里点开就行。小程序端的渲染层和逻辑层分离架构虽然刚开始用会觉得别扭但熟悉了组件生命周期和 setData 的更新机制之后做表单提交、数据展示、图表渲染这些事情并不复杂。1.2 前后端分离架构的落地方式所谓前后端分离核心不是把代码分成两个仓库或者两个目录那么简单而是要彻底切断视图和后端逻辑的耦合。后端只提供 JSON 接口前端根据接口数据渲染页面前端只关心数据交互和 UI 呈现不接触任何模板引擎和业务计算。这样做带来的直接好处有三个第一开发并行度大幅提升。前端工程师不用等后端把页面写完后端也不用等前端把页面搭好。只要提前约定好接口文档两边同时开工。做到一半发现字段不对改一下接口文档联调时对齐就行。第二部署完全解耦。后端打成一个 jar 包放服务器跑前端构建成静态资源丢到 Nginx 里小程序端则是一套独立的 wxss/wxml 代码。任何一端要升级、回滚、扩容都不影响另外两端。这在项目上线后的运维阶段非常重要。第三前后端各自使用最优的工具链。前端可以用 Vite 做构建优化、ESLint 做代码检查、Pinia 做全局状态管理后端可以上 Redis 做缓存、Spring Security 做权限控制、MyBatis-Plus 做数据持久化。两边各干各的互不拖累。我在这个项目里的具体落地方式是后端只负责接口所有接口统一返回ResultT结构体包含 code、message、data 三个字段前端根据 code 判断请求是否成功。前端通过 Axios 统一管理请求请求拦截器里自动携带 token响应拦截器里统一处理业务异常和 401 跳转。小程序端单独封装一个request.js工具模块内部封装 wx.request统一处理登录态和错误提示。接口文档统一走 SpringDocOpenAPI 3前后端各看各的接口定义减少沟通成本。1.3 功能模块划分与核心业务流程健康管理系统这种业务听名字好像就是记录健康数据但真正拆开做功能是要成体系的。我从角色角度把功能拆成三个端微信小程序端用户端注册登录微信授权 手机号绑定个人健康档案基本信息、病史、过敏史、家族史健康数据记录血压、血糖、心率、体重、体温、睡眠时长健康趋势图表按周/月展示数据变化曲线运动记录步数同步、手动录入运动类型饮食记录三餐打卡、热量估算健康建议/提醒根据最近健康数据生成建议推送提醒个人中心健康报告、消息通知、设置Vue3 管理后台管理端登录账号密码 验证码用户管理查看用户列表、用户详情、禁用/启用用户健康档案管理查看/导出用户档案健康数据管理按用户查看历史数据、异常数据标记内容管理健康资讯、健康建议模板、公告发布数据统计用户增长、活跃度、健康数据分布图表系统设置角色权限、菜单管理、操作日志后端服务SpringBoot提供 RESTful API 接口用户认证与鉴权JWT Spring Security健康数据统计与分析微信小程序登录凭证校验与 openid 绑定消息推送订阅消息数据汇聚与导出Excel 导出健康报告这里有一个特别容易忽略的点健康数据和普通业务数据不一样它有很强的时效性和私密性。数据库设计的时候健康数据表一定要带上记录时间和数据来源字段接口层要对用户做严格的数据隔离确保一个用户只能查到自己的健康数据管理端则是全局视角。这个权限边界从数据库设计开始就要划清楚不能等代码写完了再补。2. 后端核心实现与数据库设计2.1 SpringBoot 分层架构与核心功能模块后端代码的组织方式我遵循的是经典的四层结构Controller 层、Service 层、Mapper 层、Entity 层。Controller 层只做三件事接收请求参数、调用 Service、返回 Result。这里有个讲究——Controller 里绝对不能写业务逻辑哪怕是简单的判断也不要写否则代码很快会变成一锅粥。参数校验用 Spring Validation 的注解来处理比如NotBlank、Email、Min没必要在代码里写一堆 if-else。Service 层是业务逻辑的核心。以“记录血压”这个功能为例Service 层做的事情包括先根据 token 解析出用户 ID再把前端传过来的收缩压、舒张压、心率、测量时间等数据做合法性校验然后写入数据库同时根据最新的几条血压数据判断是否需要生成健康提醒。如果用户在短时间内连续录入还要做重复判断避免脏数据。Mapper 层用的是 MyBatis-Plus绝大多数单表 CRUD 直接继承BaseMapperT就行连 XML 都不用写。稍微复杂一点的统计查询我加了几条自定义 SQL配合Select注解写在 Mapper 接口上。MyBatis-Plus 的 LambdaQueryWrapper 写条件查询非常舒服比如按时间范围查询血压记录LambdaQueryWrapperBloodPressureRecord wrapper new LambdaQueryWrapper(); wrapper.eq(BloodPressureRecord::getUserId, userId) .between(BloodPressureRecord::getMeasureTime, startDate, endDate) .orderByDesc(BloodPressureRecord::getMeasureTime);认证和鉴权这块我用的是 JWT Spring Security 的组合。用户登录成功后签发 tokentoken 里只放 userId 和角色信息有效期设 7 天。每次请求带着 token 走一遍 JWT 过滤器解析出 userId 放到全局上下文中。Spring Security 的配置类里只放行登录接口、微信登录接口、验证码接口其余接口全部要求认证。这里建议把SecurityContextHolder里的用户信息封装成一个CurrentUserHolderService 层直接调用获取当前用户 ID代码会干净很多。2.2 数据库设计与 SQL 脚本的关键点数据库是这个项目的地基设计得好不好直接决定后面开发的顺畅程度。我用的是 MySQL 8.0字符集 utf8mb4存储引擎 InnoDB。SQL 脚本里包含建库、建表、插入初始数据三部分。建库时建议显式指定字符集CREATE DATABASE IF NOT EXISTS health_management DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;核心表设计如下用户表sys_user主键、用户名、密码BCrypt 加密、昵称、头像、手机号、角色 ID、状态正常/禁用、创建时间、更新时间。这里手机号要做唯一索引用户名也要做唯一索引两套登录凭证并行。用户健康档案表health_profile主键、用户 ID、姓名、性别、出生日期、身高、体重、血型、既往病史、过敏史、家族病史、紧急联系人、紧急联系电话。用户 ID 做唯一约束一个用户只有一份档案。健康记录表health_record这是核心中的核心字段包括主键、用户 ID、记录类型血压/血糖/心率/体重/体温、数值 1、数值 2、单位、测量时间、数据来源手动/设备同步、异常标记、备注。为什么用“记录类型 数值”这种通用结构而不是拆成多张表因为做统计和查询的时候一个通用表处理起来方便得多而且这个项目的记录类型是明确可控的不需要过度设计。运动记录表exercise_record用户 ID、运动类型跑步/步行/骑行/游泳等、运动时长、消耗热量、运动日期、备注。饮食记录表diet_record用户 ID、餐次早餐/午餐/晚餐/加餐、食物名称、摄入热量、记录日期。健康资讯表health_article标题、封面图、摘要、正文、发布时间、状态。系统菜单表sys_menu、角色表sys_role、角色菜单关联表这三张表支撑管理后台的动态权限。SQL 脚本里除了建表还插入了初始数据一个管理员账号admin、一份默认菜单数据、几条健康资讯样例。这些初始数据作用很大前端启动后不需要自己造数据就能直接跑通全流程。2.3 接口设计与权限控制接口设计我遵循 RESTful 风格但同时保持务实。比如POST /api/auth/login- 账号密码登录POST /api/auth/wx-login- 微信小程序登录GET /api/profile- 查看当前用户健康档案PUT /api/profile- 更新健康档案POST /api/health-records- 新增健康记录GET /api/health-records- 分页查询当前用户健康记录GET /api/health-records/trend?typebpdays30- 获取趋势数据GET /api/admin/users- 管理端查询用户列表GET /api/admin/statistics/overview- 管理端数据概览权限控制分两层。第一层是 Spring Security 的接口级控制通过PreAuthorize(hasRole(ADMIN))这种注解限制接口的角色权限。第二层是数据级控制用户端查询健康数据时SQL 里强制带上 userId 条件保证横向越权不可能发生。微信登录的流程也要特别说一下。小程序端wx.login()拿到 code传给后端/api/auth/wx-login后端拿 code 去微信官方接口换取 openid 和 session_key然后查库看这个 openid 有没有绑定过用户。有就直接签发 JWT没有就自动注册一个新账号。这个流程对用户体验很友好用户完全无感知就完成了登录。3. 前端 Vue3 与微信小程序的实现要点3.1 Vue3 管理后台的实现细节Vue3 管理后台我用的是 Vite Vue3 Pinia Vue Router Element Plus 这套组合。Vite 启动快、构建快开发体验比 Webpack 时代舒服太多。登录页需要注意的细节密码传输要用 RSA 加密后端存的是 BCrypt 哈希前端不直接传明文密码这个安全习惯要养成。验证码我用的是后端生成的图片验证码Redis 存校验值有效期 5 分钟。这里有个小坑——如果你直接在后端生成图片验证码一定要在响应头设置Cache-Control: no-store否则部分浏览器会缓存验证码图片刷新不生效。登录后的路由跳转我做了两个层面的控制一是 Vue Router 的全局前置守卫没有 token 直接跳登录页二是后端返回的菜单列表前端根据菜单数据动态生成侧边栏。这种动态路由的方式权限变更后前端不用发版刷新页面就生效。用户管理页面是典型的“搜索 表格 分页 弹窗”结构。搜索区和表格区共用一份查询参数每次搜索重置页码为 1这是最容易忘记的点。分页组件的 currentPage 和 pageSize 要和后端接口参数严格对应否则会出现“数据没变但页码在跳”的诡异 bug。数据统计页面是管理后台的一个亮点模块。我用 ECharts 做图表柱状图展示每日新增用户折线图展示活跃用户趋势饼图展示用户健康数据异常分布。ECharts 5 在 Vue3 里的引入方式很简单import * as echarts from echarts; const chartDom document.getElementById(trendChart); const chart echarts.init(chartDom); chart.setOption({ xAxis: { type: category, data: dates.value }, yAxis: { type: value }, series: [{ type: line, data: counts.value }] });注意销毁钩子里一定要调用chart.dispose()否则切换路由后内存泄漏页面多了会明显变卡。3.2 微信小程序端的关键技术小程序端的项目结构我按功能拆分包pages目录放页面components目录放自定义组件utils目录放工具函数static目录放静态资源。首页是健康总览顶部展示用户今日核心指标血压、血糖、心率下面放最近 7 天的趋势图再往下是快捷记录入口。趋势图我用的方案是ec-canvas组件封装 ECharts这个方案比手写 canvas 简单很多而且小程序兼容性做得不错。需要注意的是ec-canvas在原生小程序里的初始化时机要在页面onReady之后否则 canvas 尺寸拿不到图表会空白。记录血压页面是个典型表单页。单位切换mmHg/kPa、时间选择器、备注输入框提交前做前端校验——收缩压范围 70-250舒张压范围 40-150心率范围 30-220。这块校验不能省后端虽然也有校验但前端提前拦截能省掉一次没必要的网络请求体验差别很大。小程序里有个比较麻烦的点是跨页面传参。URL 传参只能传字符串而且长度有限制。我处理健康数据详情跳转的方式是详情页的 ID 通过 URL 传过去详情数据重新从后端拉取不依赖上一个页面传递的完整对象。这样做还有额外好处——详情页刷新后数据也是最新的不会拿到过期的展示数据。我的建议封装放在utils/request.js里核心逻辑是const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${url}, method, data, header: { Content-Type: application/json, Authorization: Bearer ${getToken()} }, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { // token 失效重新登录 login().then(() { request(url, method, data).then(resolve).catch(reject); }); } else { wx.showToast({ title: res.data.message, icon: none }); reject(res.data); } }, fail: (err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); };这个封装的亮点是 token 失效自动重新登录然后重新请求用户感知不到掉线重登这个过程。我在实际使用中发现微信小程序 7 天内 token 过期是常态如果没有这层自动重试用户体验会大打折扣。3.3 前后端联调中的跨域问题前后端分离项目跨域是绕不开的坎。开发环境里Vite 的 dev server 配代理把/api开头的请求转发到后端的 8080 端口。在vite.config.js里配置server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端代码里写/api/auth/login浏览器请求的是http://localhost:5173/api/auth/login实际上被代理转发到了http://localhost:8080/api/auth/login。整个过程浏览器无感知也不存在跨域问题。生产环境更简单Nginx 配置反向代理location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }这里有个细节要注意proxy_pass末尾的/很重要它会把/api/前缀去掉再转发。如果写错了后端接口路径会变成/api/api/xxx接口全挂。我最早部署的时候在这个地方卡了半小时排查了很久才发现是 Nginx 配置的问题。后端也不是完全不需要配置。开发环境直接全放开 CORSConfiguration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); return new CorsFilter(source); } }注意这里addAllowedOrigin和addAllowedOriginPattern的区别——允许携带凭证allowCredentialstrue的时候不能用*匹配来源要用addAllowedOriginPattern(*)。这个坑有点反直觉浏览器会直接拒绝带有凭证的跨域请求控制台报错又不明显排查起来很痛苦。4. 部署上线与实操记录4.1 环境准备与项目打包部署方案我用了最经典的组合CentOS 7 系统 MySQL 8 Nginx JDK 8。项目能跑在 JDK 8 上这是 SpringBoot 一个很大的优势——不用为了高版本 JDK 去适配新的语法和库。打包前先改配置。后端application.yml里把 MySQL 地址改成服务器 IPRedis 地址和端口也要确认可用。我习惯用application-prod.yml单独放生产环境配置避免开发配置误传到线上。多环境配置的好处是切换方便开发、测试、生产三套配置互不影响。后端的打包命令很简单mvn clean package -DskipTests打完包在target目录下会生成一个health-system.jar。上传到服务器之后用一个 nohup 命令启动nohup java -jar health-system.jar --spring.profiles.activeprod health.log 21 这个命令的意思是后台启动、日志输出到health.log、即使断开终端连接进程也继续运行。确认启动成功的命令tail -f health.log看到Started Application in xx seconds就说明启动成功了。注意生产环境一定不能用 IDE 直接跑服务要用这种后台守护方式。前端打包npm run build打包产物在dist目录。把dist目录下的文件上传到服务器 Nginx 的html目录Nginx 配置指向那个目录就行。这里有个小技巧Nginx 的index index.html要配好同时加一条try_files规则防止刷新页面 404location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }这行try_files的作用是访问不存在的路径时回退到 index.html由前端路由处理页面跳转。不加这行配置你在管理后台里刷新一个二级页面就会看到 Nginx 的 404 页面。4.2 小程序上线配置要点小程序端的部署相对特殊因为它不是放在你自己的服务器上而是上传到微信公众平台审核通过后由微信服务器托管。上线前需要在project.config.json里配置好 appid然后在小程序开发者工具里点击“上传”填好版本号和备注再到微信公众平台提交审核。小程序请求的域名必须是 HTTPS并且要在微信公众平台里配置 request 合法域名。这里有个很麻烦的限制一个用户在小程序里发起的请求域名必须是备案过的 HTTPS 域名而且不能带端口号。如果你用http://ip:8080这样的地址开发工具里能开“不校验合法域名”跑通但真机预览和上线后必挂。我的解决办法是用 Nginx 监听 443 端口配好 SSL 证书把小程序 API 的请求转发到后端的 8080 端口。这样小程序请求的是https://api.yourdomain.comNginx 再把流量转给http://127.0.0.1:8080。证书申请我用的是免费的 Let‘s Encrypt 或者阿里云免费证书一年一换成本为零。4.3 部署踩坑记录部署过程中我遇到的第一个坑是 MySQL 连接报Public Key Retrieval is not allowed原因是 MySQL 8 默认的认证插件是 caching_sha2_passwordJDBC 驱动默认不允许公钥检索。解决办法是在 JDBC 连接串上加allowPublicKeyRetrievaltrueurl: jdbc:mysql://localhost:3306/health_management?useUnicodetruecharacterEncodingutf8useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/Shanghai第二个坑是内存不足。服务器只有 2G 内存Java 服务默认的堆内存设置可能会导致启动很慢甚至 OOM。我在启动命令里加了 JVM 参数java -Xms256m -Xmx512m -jar health-system.jar把堆内存压到 512M启动速度和运行稳定性都好很多。健康管理系统这种负载512M 完全够用没必要给太多。第三个坑是 Redis 连接问题。我有一台服务器本地装了 Redis启动命令变成redis-server --daemonize yes但访问老是超时。排查之后发现是 Redis 默认只绑定了 127.0.0.1而我的 Java 服务用了公网 IP 去连连不上。解决办法是给 Redis 设密码然后绑定内网 IP同时把protected-mode设为yes。记得 Redis 一定不要裸奔在公网上设密码是最基本的操作。5. 常见问题排查与避坑经验5.1 前后端联调典型问题接口报 401 但登录接口正常检查 token 是否在请求头里正确携带。Axios 请求拦截器里一定要写成config.headers.Authorization Bearer getToken()注意 Bearer 后面有空格少了空格后端解析不到 token。接口返回的数据在页面不显示大概率是响应数据结构对不上。后端返回的是{ code, message, data }前端 Axios 响应拦截器里return res.data.data然后页面拿到的就是真正的数据。如果拦截器返回的是整个响应体页面取到的就嵌套了一层。Vue3 里修改数据页面不更新检查是不是用了普通变量而不是 reactive/ref。Vue3 的响应式系统只追踪 reactive 对象你在 setup 里声明let list []然后 push页面是完全没有反应的。必须const list ref([])或者const state reactive({ list: [] })。小程序端图片加载不出来小程序对网络图片的域名也有限制需要在微信公众平台配置“downloadFile 合法域名”。如果你只是从后端接口拿数据图片 URL 是后端的域名那就要把后端的域名也配进 request 合法域名。5.2 数据库与接口常见问题SQL 脚本执行报错检查 MySQL 版本有些函数只有 MySQL 8 才支持。比如我用到了RANK()窗口函数MySQL 5.7 直接报语法错误。如果你用的还是 MySQL 5.7看情况改掉这类写法。数据重复插入健康记录表一定要建联合唯一索引。我在这张表上加了(user_id, record_type, measure_time)的唯一索引用户同一时间点重复提交时数据库层面直接拦截比业务代码判断可靠得多。前端查询时间范围数据不对检查时间是否有时区问题。服务器时区是 UTC 的话数据库里存的是 UTC 时间前端拿到之后显示的是东八区时间就会差 8 个小时。解决方案是连接串里加serverTimezoneAsia/Shanghai同时数据库连接后执行set time_zone 08:00。体检报告导出的 Excel 中文乱码用 EasyExcel 导出时响应头设置response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet); response.setCharacterEncoding(utf-8); String fileName URLEncoder.encode(健康报告, UTF-8).replaceAll(\\, %20); response.setHeader(Content-disposition, attachment;filename*utf-8 fileName .xlsx);关键点是文件名要做 URL 编码否则浏览器下载时中文文件名直接乱码。5.3 个人实操心得做完整套系统我最大的体会是前后端分离项目真正难的不是某个技术点而是接口契约的稳定性。我踩过最深的坑就是联调阶段前端说字段名不对、后端说没传这个参数两边各改各的最后搞了一整天。后来我立了个规矩所有接口的请求参数和响应结构先写进接口文档前端基于文档做 mock 数据后端基于文档写接口。文档变化走流程不口头说改就改项目一下子就顺了。第二个体会是关于小程序提交审核的。微信审核对健康类应用比较敏感尤其是涉及用户隐私数据的功能。我提交审核时被拒了一次原因是隐私政策里没有明确说明数据的使用范围。后来在小程序后台配置了用户隐私保护指引同时在小程序端加了一个《用户协议》和《隐私政策》的弹窗确认用户点同意之后才能进入系统第二次审核就通过了。健康类小程序上线前一定要把隐私合规这块放在心上不是走过场是真会卡审核。第三个建议是给要做二开的朋友的。这套项目代码结构我是按“能接手、能扩展”的标准来写的目录命名、注释、接口风格都尽量统一。如果你拿到源码之后建议先花一小时梳理一下数据库表关系再打开后端代码看一遍 Controller 层的接口列表然后在 Vue3 管理后台里跑一遍菜单功能整体脉络就清楚了。遇到需要新增模块的场景照着现有模块复制一份改比从零开发要省太多事。健康管理系统后面还可以加的东西不少——比如对接智能手环的 SDK 自动同步运动数据、接入 AI 生成个性化健康建议、增加多语言支持等等。不过骨架已经搭好了怎么往上加内容就看各自的业务场景了。我自己后续打算加的是手机号一键登录和微信订阅消息的定时推送提醒这两个功能对用户活跃度提升应该会有明显效果。本文还有配套的精品资源点击获取
