简介这是一套面向计算机专业学生与初学者的健康管理类全栈开发实战资源适用于课程设计、毕业设计及期末大作业场景聚焦前后端分离架构下的健康数据管理需求。资源包含完整SpringBoot后端112个Java文件、Vue3前端139个Vue组件258个JS逻辑文件与微信小程序60个WXML66个WXSS2个WXS三端代码配套MySQL建库建表SQL脚本及443张界面截图等素材共1284个文件压缩包仅9.26MB轻量易部署。已有287人学习下载资源结构清晰前端样式文件CSS/SCSS、静态资源PNG/JPG、配置文件JSON/YML与构建产物CSS/JS映射文件分类明确便于理解工程组织逻辑。读者可直接运行调试掌握JWT鉴权、健康档案CRUD、运动数据可视化、小程序授权登录等核心功能实现并参考实际项目目录规范与前后端联调流程。1. 这套健康管理系统到底解决了什么问题——选型的真实逻辑我平时在技术社群里被问得最多的一个问题就是有没有一套能直接跑起来、前后端都齐、还带数据库脚本的项目说实话大多数人不是不愿意自己动手而是想要一个能真正打通用户端-管理端-服务端-数据库全链路的参考项目。这套基于 SpringBoot Vue3 微信小程序的健康管理系统就是为了解决这个需求而生的。先说清楚这套系统能做什么。它不是一个单纯的CRUD Demo而是一个具备完整业务闭环的健康管理平台。用户端是微信小程序用户可以在上面完成健康档案录入、体检记录查询、健康指标追踪、体检报告查看、慢病随访记录等管理端是Vue3搭建的Web后台运营人员或医生可以管理用户信息、录入体检数据、配置健康提醒策略、查看统计报表。后端则是SpringBoot提供RESTful API配合MySQL数据库存储所有业务数据。整体采用前后端分离架构这意味着前端页面和后端服务可以独立开发、独立部署接口通过JSON格式交互这也是目前企业级项目最主流的技术形态。为什么技术栈偏偏选这三件套我从实际项目经验来拆解一下。SpringBoot在Java后端领域已经统治了多年生态成熟、招聘需求大、遇到问题能搜到的资料最多对于学习者和中小型团队来说它是性价比最高的选择。Vue3经过两年多的迭代Composition API的写法已经相当稳定配合Vite构建工具开发体验比Vue2时代强了不止一个档次。而微信小程序就不用多说了——在国内健康管理这类C端产品小程序几乎是绕不开的入口不用安装、轻量触达、分享方便。三者的组合恰好覆盖了后端业务能力 后台管理效率 用户端触达三个核心诉求。还有一点值得提的是前后端分离这个关键词。很多初学者对前后端分离的理解只停留在前端一个项目后端一个项目的层面实际里面还有很多细节跨域如何处理、Token如何传递、接口文档怎么维护、前端构建后怎么部署、Nginx如何反向代理……这些都是面试时会问、工作中会遇到的硬知识点。这套系统的代码里这些细节全都落地了这也是它比那种前端凑合写在一个模板里的老式项目更有参考价值的原因。当然我不是说这种组合就是万能的。如果你自己动手做项目想在这套代码基础上二次开发完全可以把某一层替换掉。但如果你是为了理解全栈项目的工程结构、业务流程、前后端联调方式那么直接复现这套项目比你自己从零拼凑要快得多。接下来我会按工程结构、后端、管理后台、小程序、数据库、部署这几个维度逐层讲清楚这个项目的实现思路和值得注意的细节。2. 后端SpringBoot的工程结构与核心业务实现后端是整个系统的数据中枢所有健康数据的持久化、业务规则的执行、对外接口的提供都在这层完成。很多人拿到一个SpringBoot项目第一反应是类好多目录到底怎么分层这一节我把工程结构和核心业务模块串起来讲大家对照代码看会轻松很多。2.1 分包结构与分层职责这套系统后端采用的是经典的四层结构controller、service、mapper、entity。我见过不少人把业务逻辑直接写在Controller里图一时省事后面改一个需求要动好几个接口非常痛苦。正确的做法是Controller只做参数接收和结果返回具体的业务规则放到Service里数据访问则交给Mapper层。以体检记录这个模块为例它的工作流是这样的小程序或管理后台发起请求命中HealthCheckControllerController把请求参数交给HealthCheckServiceService内完成业务校验比如体检时间不能晚于当前时间、异常指标要给出提示、再掉HealthCheckMapper操作数据库。com.health ├── controller # 接口层只处理请求与响应 ├── service # 业务层核心逻辑都在这里 ├── mapper # MyBatis-Plus数据访问层 ├── entity # 数据库表对应的实体类 ├── common # 公共类统一返回、异常处理、工具类 ├── config # 配置类跨域、拦截器、WebMVC等 └── HealthApplication.java这样的分层带来的最大好处是职责清晰。面试时候被问到SpringBoot项目怎么设计包结构你把这个结构讲出来再说明每一层存在的意义基本就过关了。2.2 JWT认证与用户身份识别健康管理系统涉及用户的敏感数据接口不可能裸奔。这套系统采用JWTJSON Web Token来做登录态管理。流程是这样的用户通过微信小程序端登录后端收到微信的code后调用微信接口换取openid然后用openid去数据库找用户。如果用户首次使用系统自动帮他创建账号如果已存在则直接签发Token返回给前端。这里有个细节值得展开说说。签发Token的时候不能只把用户ID放进去还需要把用户的角色类型放进去。因为这套系统有两类使用方普通用户和后台管理员。管理员通过账号密码登录管理后台普通用户通过微信授权登录小程序。如果Token里没有角色信息后端每次接口鉴权都得再查一次数据库多一次IO开销不说逻辑也绕。我自己在实际项目里踩过Token过期的坑。JWT是自包含的签发之后在有效期内无法主动使其失效所以这套系统里设置了合理的过期时间——小程序端Token有效期7天管理后台Token有效期2小时。对于需要更严格控制的场景比如修改密码后要求所有旧Token失效可以引入Token黑名单机制把用户ID签发时间存到Redis里做校验。虽然这套基础版没有上Redis但理解了这个演进方向后面自己扩展就不慌。2.3 核心业务模块与接口设计后端主要的业务模块包含用户管理、健康档案、体检记录、慢病随访、健康提醒五块。用户管理这块主要是用户CRUD、状态启停用、和小程序openid的绑定。有个细节用户表的设计要考虑手机号、身份证号等敏感信息。虽然MVP阶段可以明文存储但生产环境为了保证安全建议对身份证号做AES加密或脱敏存储。如果是正经商用的健康管理平台还涉及等保要求和隐私合规问题这些都要提前想清楚。健康档案是用户在小程序端自己填写或修改的基础信息包括身高、体重、既往病史、过敏史等。这类信息时效性强所以数据库设计时不要只存一份最好加一个更新时间字段这样后台统计时能区分多久没有更新档案的用户方便运营干预。体检记录是系统的核心数据来源管理后台可以由医生维护小程序端用户也可以自行上传。每条体检记录包含多项指标数据比如血糖、血脂、血压、尿酸等。这里的设计重点在于体检指标往往不是固定的不同体检机构项目也不一样。这套系统采用的方案是主表明细表主表存一次体检的基本信息体检机构、体检日期、总结论明细表存每一项指标的名称、数值、单位、参考范围、是否异常。这种设计能从根源上适应体检项目不断变化的需求不用频繁改表结构。慢病随访是健康管理中非常重要的一环。系统根据体检结果中有异常的指标自动生成随访计划。例如某用户连续两次体检的空腹血糖都超过6.1mmol/L系统就会标记出糖代谢异常风险后台会生成一条随访任务分配给指定的医生或健康管理师。这个逻辑在代码里用状态机式的状态流转来控制待随访→随访中→已完成状态变更时记录操作日志方便审计追踪。健康提醒与定时任务相关。系统里有多个定时任务比如每天早上8点给有随访计划的用户推送服药提醒、每周一统计上周新增的异常指标数据并推送给运营人员。SpringBoot里实现定时任务很简单在启动类或者配置类上标注EnableScheduling然后在具体任务方法上加Scheduled(cron 0 0 8 * * ?)就行了。2.4 统一返回结果与全局异常处理你如果长期看各类开源项目会发现好的后端代码都有一个共同点接口返回结构统一。这套系统定义了一个Result类所有接口都返回固定的JSON结构public class ResultT { private Integer code; // 200成功500失败 private String msg; // 提示信息 private T data; // 业务数据 // getter/setter/构造方法省略 }这样做的好处是前端处理响应时只要写一套拦截逻辑不需要每个接口单独判断返回格式。前端拿到code为200就走成功分支弹错误提示时统一读取msg字段。与之配套的是全局异常处理。如果不做全局异常处理代码里每一个接口都要用try-catch包一遍业务逻辑不仅冗余还容易遗漏。SpringBoot里用RestControllerAdvice可以非常优雅地解决这个问题RestControllerAdvice public class GlobalExceptionHandler { ExceptionHandler(BusinessException.class) public Result? handleBusinessException(BusinessException e) { return Result.error(e.getCode(), e.getMessage()); } ExceptionHandler(Exception.class) public Result? handleException(Exception e) { log.error(系统异常, e); return Result.error(500, 系统繁忙请稍后重试); } }通过这种方式业务代码里只需要用throw new BusinessException(体检日期不能晚于当前)就能把错误信息传给前端非常干净。这是SpringBoot面试题中说说你怎么处理全局异常的标准答案也是实际开发中必需的代码规范。3. Vue3管理后台的落地细节不是能跑而是好用管理后台是运营人员天天面对的界面能不能提升他们的工作效率直接决定了这个系统的落地价值。这套后台的前端技术栈是Vue3 Vite Pinia Element Plus这也是目前Vue3生态里最主流的组合。如果你去面试问Vue3项目怎么做状态管理答案一定是Pinia——它比Vuex更轻量TypeScript支持更好没有mutations概念store的代码写起来明显简洁。3.1 登录态管理与动态路由权限后台登录走的是账号密码模式后端校验通过后返回Token前端把Token存到localStorage并在后续每次请求的请求头里带上Authorization: Bearer ${token}。这里有一个核心设计路由守卫。不管用户直接访问哪个URL都要先确认有没有Token没有就强制跳转到登录页有Token但用户信息为空就拉取一次用户信息。路由权限这块这套系统用的是动态路由方案。后端根据管理员角色返回可访问的菜单列表前端拿到菜单后用router.addRoute把对应的路由动态添加进去。这种方案的优点是权限配置在后端管理前端改权限只需调接口不用发版本。如果是在简单的内部管理系统里也可以用前端路由表写死路由守卫判断角色的方案来降低复杂度但一旦菜单项变多、角色变多还是建议上动态路由这套系统的做法值得直接参考。3.2 组件化开发与Vue3核心API的使用经验Vue3项目开发过程中defineProps和defineEmits是使用频率最高的两个API它们用来在父子组件之间传数据。举一个很常见的场景主页有一个用户列表组件点击列表里某一行需要弹出一个用户详情对话框。这时候父组件负责控制对话框的显示状态把选中用户的数据通过props传给子组件子组件内部编辑完数据后通过emit触发一个事件告诉父组件数据改过了重新拉列表。!-- 父组件 -- user-detail :visibledialogVisible :user-idcurrentUserId refreshloadUserList closedialogVisible false / !-- 子组件 -- script setup const props defineProps({ visible: { type: Boolean, default: false }, userId: { type: Number, required: true } }) const emit defineEmits([refresh, close]) function handleSave() { // 调用保存接口 emit(refresh) emit(close) } /script这套系统里几乎所有的交互页面都按这样的模式拆分。有个容易被忽视的坑如果父子组件之间传递的是对象类型props是引用传递子组件里直接修改props对象的属性会改变父组件的数据源这会造成数据流不清晰。正确做法是用computed或watch来做一层拷贝修改副本需要提交时通过emit让父组件去更新。3.3 页面布局表格、表单、筛选器、图表管理后台的页面结构高度相似但又是所有管理系统的核心几乎清一色是顶部筛选条件 中间数据表格 右上角操作按钮 底部翻页。我用这套系统里的体检记录管理页作为模板大家可以照这个思路去套其他页面。筛选区这块要注意的是查询条件必须和后端接口的查询参数一一对应像日期范围查询前端传给后端的是两个时间字段startDate和endDate后端Service层再把它转成条件构造器。表格列则要根据业务需求设置好宽度、对齐方式、格式化。比如体检日期是时间戳格式展示前要用dayjs格式化成YYYY-MM-DD。操作列放编辑、删除按钮删除必须二次确认——这个习惯很多人会忽略但真实业务中用户误删一条数据可能是很难恢复的。健康管理系统里还有一块特有功能统计图表。比如用户体检指标趋势图就用了ECharts来实现。Vue3里使用ECharts的常见做法是在组件销毁时调用chart.dispose()释放图表实例否则页面频繁切换时会出现内存泄漏。3.4 前端文件导出PDF的实现方案很多后台管理系统都有导出PDF、Excel的需求。这套系统里有一个体检报告PDF导出功能前端是把后端返回的HTML内容交给浏览器打印成PDF。后端用模板引擎将体检数据渲染为一个排版好的HTML页面前端通过iframe加载这个HTML再调用iframe的打印方法。这样一来PDF的排版完全由后端控制前端代码非常简洁。但如果数据量特别大比如要一次性导出几千条用户记录的Excel前端渲染就会卡顿。此时最佳实践是前端只需要向后端接口传递筛选条件由后端生成文件并返回下载链接前端用window.location.href downloadUrl触发下载。这样既保证了性能还减少了网络传输的体积。有经验的后端开发会在导出接口上做一层防重复提交因为用户在导出大量数据时等待时间较长可能会不停地点击导出按钮导致数据库压力过大。4. 微信小程序端从账号绑定到首页数据可视化的实现思路小程序端是普通用户接触系统的第一入口它的体验直接决定了用户愿不愿意持续使用这个健康管理工具。这一节重点讲几个小程序开发里必须掌握的细节微信登录流程、页面布局适配、组件间通信以及分包异步化的实际应用。4.1 微信登录与账号绑定的完整流程小程序的登录流程和传统Web登录完全不同。用户在Web端输入账号密码但小程序端用户不可能愿意去记一个账号密码尤其是一般健康管理App的目标人群还包括中老年人。微信生态下的标准做法是第一步小程序端调用wx.login()获取一个临时code。第二步把这个code通过后端接口传给SpringBoot服务。第三步后端拿着code去调用微信官方的https://api.weixin.qq.com/sns/jscode2session接口换取该用户唯一的openid。第四步后端查数据库里是否已存在这个openid如果不存在就自动创建一个默认账号存在则直接签发JWT返回给前端。第五步后续所有接口请求都带上这个JWT后端通过JWT解析出用户身份。这套流程里有个关键点我建议单独记一下拿到用户信息昵称、头像之后不要每次启动小程序都弹窗要求授权现在微信对用户隐私的管控越来越严格频繁获取用户信息很容易被封禁相关能力。项目里的方法是用户默认就是微信用户的昵称等用户主动进入我的页面去完善个人资料时再引导补充信息。4.2 首页健康指标卡片与数据展示首页是用户每次打开小程序最先看到的界面需要把用户最关心的核心健康指标展示出来。这个页面有两个核心难点一是数据的动态加载二是页面的布局适配。数据流上首页生命周期函数onShow里调一个聚合接口后端返回用户最新一次的体检记录信息包含血压、血糖、BMI这类关键指标。前端拿到结果后渲染到卡片上。这里要注意接口返回的时间字段是时间戳小程序端在WXML里没法直接做复杂格式化所以标准的做法是后端在返回时就把前端需要的展示格式算好比如signTime: 2025-01-15、isAbnormal: true前端只负责摆放位置。布局适配这个问题做小程序的人几乎都被坑过。不同的手机机型顶部导航栏高度不一样。iPhone X以后有刘海屏状态栏高度大约是44px普通安卓机是20px左右。如果用写死的CSS高度来布局很容易出现内容被刘海遮挡或者整体布局往下偏移的问题。推荐的做法// 适用微信小程序 const systemInfo wx.getSystemInfoSync() // 胶囊按钮位置信息 const menuButton wx.getMenuButtonBoundingClientRect() // 导航栏高度 胶囊顶部到状态栏底部的距离 * 2 胶囊高度 const navBarHeight (menuButton.top - systemInfo.statusBarHeight) * 2 menuButton.height这套系统在封装自定义导航栏时就是在app.js里先算好这些高度数据存到globalData里页面加载时直接读取使用省去了每个页面重复计算的麻烦。4.3 表单组件的选用单选、多选还是自定义选择器小程序里用户录入健康档案时会遇到很多选一项或者选多项的场景比如既往病史、过敏史、家族病史。微信小程序原生提供了picker组件它适合做那种点击后从底部弹起的滚筒选择器。但如果选项特别多比如既往病史可能有十几项甚至二十项滚动选择就太闹心了。这种场景我会优先选择用标签式多选一行展示若干个小标签用户直接点击选择选中状态用颜色区分。交互效率更高对不习惯滚动的中老年用户也更友好。对于必填项、选填项的区分在UI上要有明显标识。比如必填项用红色星号选填项则灰色提示。表单提交前必须做一次校验不符合规则的直接Toast提示不要等提交到后端再返回一堆错误信息浪费用户时间。这也是小程序端开发体验里最容易被低估的一个点——前端能拦住的错误坚决不要发给后端。4.4 分包异步化的实际使用场景随着项目功能越来越多小程序主包的体积很容易超过2MB的发布限制。这套健康管理系统在开发初期就考虑了分包把体检记录、健康档案这两个相对独立的功能拆到了子包中。分包带来的收益是主包体积减小小程序冷启动速度变快。而分包异步化则是微信小程序的一个进阶能力。传统分包的页面在使用其他分包的组件时必须把组件放到同一个包内否则会报错。通过分包异步化子包页面可以直接使用另一个子包的组件——小程序在编译时会把组件依赖关系记录下来运行时按需下载对应的分包。实际落地时我建议把公共的、体积较大的、使用频率低的图表组件放到一个独立的component分包里需要时再加载这样首屏体验会好很多。不过需要提醒的是分包异步化虽然好用但如果过度拆分会导致分包数量过多、碎片化严重反而拉低加载性能。一个原则是主包只放核心入口页和必要的基础库文件其他功能按业务域划分到各自的分包每个分包不要做得特别小避免几百K大小的模块满天飞。5. SQL脚本与数据库设计真正让系统跑起来的基石代码写得再好如果数据库表结构设计不合理项目一样是空中楼阁。这套系统的SQL脚本里包含了建库、建表、初始化数据三个部分拿到项目后先执行SQL脚本再启动后端接口才能正常返回数据。下面我重点讲一下表结构的设计思路和SQL脚本里值得借鉴的细节。5.1 核心表结构设计整套系统主要包含这几张核心表用户表是基础中的基础字段设计上除了常规的用户名、手机号、昵称以外要特别设计一个openid字段并且加上唯一索引。因为微信小程序的登录流程决定了同一用户有且只能有一个openid如果数据库里不限制唯一性就会出现重复账号的脏数据。体检记录表是业务核心其中体检结论、异常项建议用文本字段保存但为了便于统计需要设计一个风险等级字段比如1表示正常2表示轻度异常3表示明显异常。管理后台做数据筛选时直接按这个字段做等值查询比在文本里用like去模糊匹配效率高得多。体检明细表设计了指标名称、指标值、单位、参考范围下限、参考范围上限、是否异常等字段。这里有个设计细节是否异常这个字段不一定要在插入数据时手工指定。完全可以由后端在保存体检记录时自动比对指标值与参考范围后写入。这样数据库里存的永远是规范化的结果前端展示时不用做二次计算。5.2 SQL脚本的组织方式与初始化数据SQL脚本的顺序很讲究。先删表再建表是一般的惯例DROP TABLE IF EXISTS防止重复执行报错。再按照表之间的依赖关系来创建先创建无外键依赖的基础表比如用户表、角色表再创建业务表比如体检记录表、随访计划表。最后再插入初始化数据。你如果拿到这套系统的SQL脚本会发现里面会有一段初始化管理员账号的INSERT语句。这个是很实用的技巧——项目部署后不用你自己手动往数据库里塞管理员账号直接用一个预设账号密码登录系统。要注意的坑是初始化数据里的密码一定不能是明文这个脚本里对初始密码进行了BCrypt加密这也是Spring Security体系中主流的密码加密方案。5.3 MyBatis-Plus的使用与SQL编写注意事项项目的持久层框架用的是MyBatis-Plus它对单表的CRUD操作封装得非常到位日常开发中大多数接口都不用手写SQL直接继承BaseMapper就能获得selectById、selectPage、insert等基础方法。但对于多表关联查询尤其是报表统计类需求手写SQL还是最直接的方式。调试时有一个很关键的配置在application.yml里开启SQL日志打印开发环境能看到每个请求实际执行的SQL语句。排查接口数据不对之类的问题第一步就是看日志里的SQL到底是什么mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl另外要特别提醒字段命名的问题。数据库字段在项目里统一用下划线风格比如health_check_dateJava实体类用驼峰命名比如healthCheckDate。MyBatis-Plus默认开启了驼峰转换所以框架会自动映射但如果某个字段在实体类里命名不规范例如用了healthcheckdate这种全小写的写法映射就会失败接口返回null排查时特别容易忽略。这个坑我在接手别人的老项目时踩过不止一次。6. 前后端分离部署从本地到服务器的完整实操前后端分离项目的部署是一个完全独立于开发阶段的知识点。很多人在本地开发环境跑得好好的一到服务器部署就各种报错。这一节我把部署的完整流程和关键细节梳理一遍按照这个顺序操作能少走很多弯路。6.1 部署架构与核心原则本地开发时前端通过Vite的dev server运行在5173端口后端占8080端口两者之间有跨域问题所以开发环境用了Vite的proxy配置来做代理转发。在生产环境前端构建后生成的是静态文件HTML、CSS、JS这些文件直接交给Nginx托管后端接口依然是一个Java进程监听某个端口。关键是利用Nginx的reverse proxy特性把/api开头的请求转发到后端的Java服务上。这样对于浏览器来说所有请求都在同一个域名下不存在跨域问题。简化后的架构就是浏览器访问Nginx80端口→ Nginx托管前端静态文件 → 匹配到/api的请求转发到Java应用8080端口→ Java应用再访问MySQL3306端口。6.2 后端打包的坑与解决方案SpringBoot的打包方式很简单在项目根目录执行mvn clean package -DskipTests就会在target目录生成一个可执行的jar包。启动时用nohup java -jar health-manage.jar app.log 21 即可让应用在后台运行。这里要提醒几个常见的坑第一个坑是SpringBoot版本太高。很多新手从仓库拉下来的项目用的是最新的SpringBoot 3.x但本地JDK还是8或者11启动直接报错。SpringBoot 3.x强制要求JDK17及以上如果你的服务器还是JDK8就老老实实把SpringBoot版本降到2.7.x或者升级服务器的JDK。用这套系统的时候最好先看一眼项目的pom.xml里写的Java版本避免安装完环境才发现对不上。第二个坑是打包时jar包体积过大。SpringBoot默认用spring-boot-maven-plugin打成可执行jar里面包含了所有依赖比如一个简单项目也有50MB以上这很正常。不要试图把它拆成小jar包除非你很清楚自己在做什么。第三个坑是配置文件里写了本机地址。这个问题很容易踩——本地开发时数据库URL写的是localhost:3306生产环境的数据库一般不会和Java应用在同一台机器上。所以部署前一定要把application.yml里的数据库地址、用户名、密码改成生产环境的值。6.3 前端构建与Nginx配置前端构建命令很简单在项目根目录执行npm run buildVite会生成一个dist目录这个目录就是所有的静态文件。把dist目录下的所有文件上传到服务器的指定目录比如/usr/share/nginx/html/health然后在Nginx配置里添加一个server块指向它。关键的Nginx配置如下server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/health; index index.html; # 前端路由Vue Router的history模式需要这个配置 location / { try_files $uri $uri/ /index.html; } # 接口反向代理 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; } }try_files $uri $uri/ /index.html这个配置是Vue Router使用路由守卫后必须加的。如果不加用户在管理后台点击刷新按钮或者把某个路由地址分享给同事Nginx找不到对应的HTML文件就会返回404。加了这段配置后所有找不到的路径都会回归到index.html由前端路由接管。还有一点是HTTPS。小程序正式版要求所有请求域名必须配置在微信公众平台的合法域名里同时要求必须使用HTTPS。部署到生产环境时别忘了用SSL证书把HTTPS配上。如果只是学习阶段用开发者工具预览可以在开发者工具里勾选不校验合法域名来绕过限制。6.4 部署过程中最容易碰到的报错这段时间整理下来以下几个报错出现的频率最高启动Java应用时报端口被占用解决方案是先用netstat -tlnp | grep 8080找到占用进程kill -9掉再重新启动。或者更稳妥的方案是把Java应用的端口改掉比如放到8088。前端页面能打开但接口一直报500先不要急着去看Java日志。先确认Nginx配置里的proxy_pass有没有写对再确认Java应用有没有成功连接上数据库。很多时候是数据库的IP地址白名单没开被数据库服务端拒绝了。时间字段显示不对SpringBoot默认返回的日期格式是带T的ISO格式比如2025-01-15T10:30:00但前端想展示成YYYY-MM-DD HH:mm:ss。解决办法是在后端application.yml里配置一下Jackson的日期格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT87. 项目复现的完整路径与常见问题排查如果你拿到这套系统的代码想从头到尾跑起来我建议按照下面的顺序操作每一步确认没问题再进入下一步第一步检查环境。JDK版本、Maven版本、Node版本、MySQL版本都要先确认。项目里我默认用的是JDK8、MySQL5.7或8.0、Node16以上。环境不对后面哪里出问题都不奇怪。第二步初始化数据库。用Navicat或命令行工具执行SQL脚本确认所有表创建成功管理员账号存在。第三步启动后端。改好数据库连接配置执行mvn spring-boot:run或在IDE里直接运行启动类看到Started HealthApplication日志说明启动成功。然后用Postman或Apifox测试一个简单的接口比如登录接口能拿到Token就说明后端工作正常。第四步启动管理后台。执行npm install安装依赖然后npm run dev。很多人在这一步会遇到依赖安装慢的问题可以设置淘宝镜像源解决。启动后能打开登录页并成功登入管理后台说明前后端打通了。第五步启动小程序。用微信开发者工具导入小程序项目修改project.config.js里的appid为自己小程序的appid再把请求的baseUrl改成你本地的后端地址。开发者工具里勾选不校验合法域名以便本地联调。如果你在复现过程中遇到页面白屏的问题极大概率是接口请求失败。按F12打开调试面板看Network标签页里的请求状态一个一个排查。经常是后端接口返回了500但前端代码里没有做错误提示表现为页面卡在Loading状态。这就是为什么我在前端代码里统一封装了响应拦截器非200状态码一律Toast展示错误信息——排查问题的时候体验会好很多。另外一个常见的困惑是为什么代码一模一样在别人机器上能跑在我这就报错这个问题的答案大多数时候是版本不一致。Java的编译版本、Maven的仓库版本、Node依赖的lock文件版本一个字段对不上就可能引起莫名其妙的Bug。所以复现项目时尽量先用项目自带的工具版本配置跑通了再升级别上来就全用最新的。最后再分享一点我的实际体会做这种全栈项目最大的收获不是我写了一个能跑的系统而是通过完整地走一遍需求分析、表结构设计、接口开发、前端联调、应用部署把一个事情从头到尾吃透了。尤其是前后端分离项目真正难的不是某个单一技术点而是理解浏览器、前端工程、后端服务、数据库这几层之间是怎么协同工作的。我在做这套健康管理系统的时候最费心思的不是写代码本身而是理清业务关系谁可以看哪些数据、体检指标异常了怎么流转、健康提醒在什么条件下触发、随访任务如何闭环。这些抽象的业务规则最终变成数据库表字段、接口定义和前端状态。这个过程走通了后面再接手任何业务系统你都会觉得套路都差不多心里有底。如果你只是刚学完SpringBoot和Vue3的基础语法建议先别急着做那种图书管理学生管理的简单CRUD直接拿这种带完整业务链路的项目来练手收获会大得多。跑通之后试着改一两个需求比如给小程序加一个健康资讯栏目或者给后台加一个体检异常趋势分析图表改到自己满意为止。这种实战带来的经验是看再多教程都替代不了的。本文还有配套的精品资源点击获取 基于SpringBoot+Vue3+微信小程序的全栈健康管理系统实战解析
简介这是一套面向计算机专业学生与初学者的健康管理类全栈开发实战资源适用于课程设计、毕业设计及期末大作业场景聚焦前后端分离架构下的健康数据管理需求。资源包含完整SpringBoot后端112个Java文件、Vue3前端139个Vue组件258个JS逻辑文件与微信小程序60个WXML66个WXSS2个WXS三端代码配套MySQL建库建表SQL脚本及443张界面截图等素材共1284个文件压缩包仅9.26MB轻量易部署。已有287人学习下载资源结构清晰前端样式文件CSS/SCSS、静态资源PNG/JPG、配置文件JSON/YML与构建产物CSS/JS映射文件分类明确便于理解工程组织逻辑。读者可直接运行调试掌握JWT鉴权、健康档案CRUD、运动数据可视化、小程序授权登录等核心功能实现并参考实际项目目录规范与前后端联调流程。1. 这套健康管理系统到底解决了什么问题——选型的真实逻辑我平时在技术社群里被问得最多的一个问题就是有没有一套能直接跑起来、前后端都齐、还带数据库脚本的项目说实话大多数人不是不愿意自己动手而是想要一个能真正打通用户端-管理端-服务端-数据库全链路的参考项目。这套基于 SpringBoot Vue3 微信小程序的健康管理系统就是为了解决这个需求而生的。先说清楚这套系统能做什么。它不是一个单纯的CRUD Demo而是一个具备完整业务闭环的健康管理平台。用户端是微信小程序用户可以在上面完成健康档案录入、体检记录查询、健康指标追踪、体检报告查看、慢病随访记录等管理端是Vue3搭建的Web后台运营人员或医生可以管理用户信息、录入体检数据、配置健康提醒策略、查看统计报表。后端则是SpringBoot提供RESTful API配合MySQL数据库存储所有业务数据。整体采用前后端分离架构这意味着前端页面和后端服务可以独立开发、独立部署接口通过JSON格式交互这也是目前企业级项目最主流的技术形态。为什么技术栈偏偏选这三件套我从实际项目经验来拆解一下。SpringBoot在Java后端领域已经统治了多年生态成熟、招聘需求大、遇到问题能搜到的资料最多对于学习者和中小型团队来说它是性价比最高的选择。Vue3经过两年多的迭代Composition API的写法已经相当稳定配合Vite构建工具开发体验比Vue2时代强了不止一个档次。而微信小程序就不用多说了——在国内健康管理这类C端产品小程序几乎是绕不开的入口不用安装、轻量触达、分享方便。三者的组合恰好覆盖了后端业务能力 后台管理效率 用户端触达三个核心诉求。还有一点值得提的是前后端分离这个关键词。很多初学者对前后端分离的理解只停留在前端一个项目后端一个项目的层面实际里面还有很多细节跨域如何处理、Token如何传递、接口文档怎么维护、前端构建后怎么部署、Nginx如何反向代理……这些都是面试时会问、工作中会遇到的硬知识点。这套系统的代码里这些细节全都落地了这也是它比那种前端凑合写在一个模板里的老式项目更有参考价值的原因。当然我不是说这种组合就是万能的。如果你自己动手做项目想在这套代码基础上二次开发完全可以把某一层替换掉。但如果你是为了理解全栈项目的工程结构、业务流程、前后端联调方式那么直接复现这套项目比你自己从零拼凑要快得多。接下来我会按工程结构、后端、管理后台、小程序、数据库、部署这几个维度逐层讲清楚这个项目的实现思路和值得注意的细节。2. 后端SpringBoot的工程结构与核心业务实现后端是整个系统的数据中枢所有健康数据的持久化、业务规则的执行、对外接口的提供都在这层完成。很多人拿到一个SpringBoot项目第一反应是类好多目录到底怎么分层这一节我把工程结构和核心业务模块串起来讲大家对照代码看会轻松很多。2.1 分包结构与分层职责这套系统后端采用的是经典的四层结构controller、service、mapper、entity。我见过不少人把业务逻辑直接写在Controller里图一时省事后面改一个需求要动好几个接口非常痛苦。正确的做法是Controller只做参数接收和结果返回具体的业务规则放到Service里数据访问则交给Mapper层。以体检记录这个模块为例它的工作流是这样的小程序或管理后台发起请求命中HealthCheckControllerController把请求参数交给HealthCheckServiceService内完成业务校验比如体检时间不能晚于当前时间、异常指标要给出提示、再掉HealthCheckMapper操作数据库。com.health ├── controller # 接口层只处理请求与响应 ├── service # 业务层核心逻辑都在这里 ├── mapper # MyBatis-Plus数据访问层 ├── entity # 数据库表对应的实体类 ├── common # 公共类统一返回、异常处理、工具类 ├── config # 配置类跨域、拦截器、WebMVC等 └── HealthApplication.java这样的分层带来的最大好处是职责清晰。面试时候被问到SpringBoot项目怎么设计包结构你把这个结构讲出来再说明每一层存在的意义基本就过关了。2.2 JWT认证与用户身份识别健康管理系统涉及用户的敏感数据接口不可能裸奔。这套系统采用JWTJSON Web Token来做登录态管理。流程是这样的用户通过微信小程序端登录后端收到微信的code后调用微信接口换取openid然后用openid去数据库找用户。如果用户首次使用系统自动帮他创建账号如果已存在则直接签发Token返回给前端。这里有个细节值得展开说说。签发Token的时候不能只把用户ID放进去还需要把用户的角色类型放进去。因为这套系统有两类使用方普通用户和后台管理员。管理员通过账号密码登录管理后台普通用户通过微信授权登录小程序。如果Token里没有角色信息后端每次接口鉴权都得再查一次数据库多一次IO开销不说逻辑也绕。我自己在实际项目里踩过Token过期的坑。JWT是自包含的签发之后在有效期内无法主动使其失效所以这套系统里设置了合理的过期时间——小程序端Token有效期7天管理后台Token有效期2小时。对于需要更严格控制的场景比如修改密码后要求所有旧Token失效可以引入Token黑名单机制把用户ID签发时间存到Redis里做校验。虽然这套基础版没有上Redis但理解了这个演进方向后面自己扩展就不慌。2.3 核心业务模块与接口设计后端主要的业务模块包含用户管理、健康档案、体检记录、慢病随访、健康提醒五块。用户管理这块主要是用户CRUD、状态启停用、和小程序openid的绑定。有个细节用户表的设计要考虑手机号、身份证号等敏感信息。虽然MVP阶段可以明文存储但生产环境为了保证安全建议对身份证号做AES加密或脱敏存储。如果是正经商用的健康管理平台还涉及等保要求和隐私合规问题这些都要提前想清楚。健康档案是用户在小程序端自己填写或修改的基础信息包括身高、体重、既往病史、过敏史等。这类信息时效性强所以数据库设计时不要只存一份最好加一个更新时间字段这样后台统计时能区分多久没有更新档案的用户方便运营干预。体检记录是系统的核心数据来源管理后台可以由医生维护小程序端用户也可以自行上传。每条体检记录包含多项指标数据比如血糖、血脂、血压、尿酸等。这里的设计重点在于体检指标往往不是固定的不同体检机构项目也不一样。这套系统采用的方案是主表明细表主表存一次体检的基本信息体检机构、体检日期、总结论明细表存每一项指标的名称、数值、单位、参考范围、是否异常。这种设计能从根源上适应体检项目不断变化的需求不用频繁改表结构。慢病随访是健康管理中非常重要的一环。系统根据体检结果中有异常的指标自动生成随访计划。例如某用户连续两次体检的空腹血糖都超过6.1mmol/L系统就会标记出糖代谢异常风险后台会生成一条随访任务分配给指定的医生或健康管理师。这个逻辑在代码里用状态机式的状态流转来控制待随访→随访中→已完成状态变更时记录操作日志方便审计追踪。健康提醒与定时任务相关。系统里有多个定时任务比如每天早上8点给有随访计划的用户推送服药提醒、每周一统计上周新增的异常指标数据并推送给运营人员。SpringBoot里实现定时任务很简单在启动类或者配置类上标注EnableScheduling然后在具体任务方法上加Scheduled(cron 0 0 8 * * ?)就行了。2.4 统一返回结果与全局异常处理你如果长期看各类开源项目会发现好的后端代码都有一个共同点接口返回结构统一。这套系统定义了一个Result类所有接口都返回固定的JSON结构public class ResultT { private Integer code; // 200成功500失败 private String msg; // 提示信息 private T data; // 业务数据 // getter/setter/构造方法省略 }这样做的好处是前端处理响应时只要写一套拦截逻辑不需要每个接口单独判断返回格式。前端拿到code为200就走成功分支弹错误提示时统一读取msg字段。与之配套的是全局异常处理。如果不做全局异常处理代码里每一个接口都要用try-catch包一遍业务逻辑不仅冗余还容易遗漏。SpringBoot里用RestControllerAdvice可以非常优雅地解决这个问题RestControllerAdvice public class GlobalExceptionHandler { ExceptionHandler(BusinessException.class) public Result? handleBusinessException(BusinessException e) { return Result.error(e.getCode(), e.getMessage()); } ExceptionHandler(Exception.class) public Result? handleException(Exception e) { log.error(系统异常, e); return Result.error(500, 系统繁忙请稍后重试); } }通过这种方式业务代码里只需要用throw new BusinessException(体检日期不能晚于当前)就能把错误信息传给前端非常干净。这是SpringBoot面试题中说说你怎么处理全局异常的标准答案也是实际开发中必需的代码规范。3. Vue3管理后台的落地细节不是能跑而是好用管理后台是运营人员天天面对的界面能不能提升他们的工作效率直接决定了这个系统的落地价值。这套后台的前端技术栈是Vue3 Vite Pinia Element Plus这也是目前Vue3生态里最主流的组合。如果你去面试问Vue3项目怎么做状态管理答案一定是Pinia——它比Vuex更轻量TypeScript支持更好没有mutations概念store的代码写起来明显简洁。3.1 登录态管理与动态路由权限后台登录走的是账号密码模式后端校验通过后返回Token前端把Token存到localStorage并在后续每次请求的请求头里带上Authorization: Bearer ${token}。这里有一个核心设计路由守卫。不管用户直接访问哪个URL都要先确认有没有Token没有就强制跳转到登录页有Token但用户信息为空就拉取一次用户信息。路由权限这块这套系统用的是动态路由方案。后端根据管理员角色返回可访问的菜单列表前端拿到菜单后用router.addRoute把对应的路由动态添加进去。这种方案的优点是权限配置在后端管理前端改权限只需调接口不用发版本。如果是在简单的内部管理系统里也可以用前端路由表写死路由守卫判断角色的方案来降低复杂度但一旦菜单项变多、角色变多还是建议上动态路由这套系统的做法值得直接参考。3.2 组件化开发与Vue3核心API的使用经验Vue3项目开发过程中defineProps和defineEmits是使用频率最高的两个API它们用来在父子组件之间传数据。举一个很常见的场景主页有一个用户列表组件点击列表里某一行需要弹出一个用户详情对话框。这时候父组件负责控制对话框的显示状态把选中用户的数据通过props传给子组件子组件内部编辑完数据后通过emit触发一个事件告诉父组件数据改过了重新拉列表。!-- 父组件 -- user-detail :visibledialogVisible :user-idcurrentUserId refreshloadUserList closedialogVisible false / !-- 子组件 -- script setup const props defineProps({ visible: { type: Boolean, default: false }, userId: { type: Number, required: true } }) const emit defineEmits([refresh, close]) function handleSave() { // 调用保存接口 emit(refresh) emit(close) } /script这套系统里几乎所有的交互页面都按这样的模式拆分。有个容易被忽视的坑如果父子组件之间传递的是对象类型props是引用传递子组件里直接修改props对象的属性会改变父组件的数据源这会造成数据流不清晰。正确做法是用computed或watch来做一层拷贝修改副本需要提交时通过emit让父组件去更新。3.3 页面布局表格、表单、筛选器、图表管理后台的页面结构高度相似但又是所有管理系统的核心几乎清一色是顶部筛选条件 中间数据表格 右上角操作按钮 底部翻页。我用这套系统里的体检记录管理页作为模板大家可以照这个思路去套其他页面。筛选区这块要注意的是查询条件必须和后端接口的查询参数一一对应像日期范围查询前端传给后端的是两个时间字段startDate和endDate后端Service层再把它转成条件构造器。表格列则要根据业务需求设置好宽度、对齐方式、格式化。比如体检日期是时间戳格式展示前要用dayjs格式化成YYYY-MM-DD。操作列放编辑、删除按钮删除必须二次确认——这个习惯很多人会忽略但真实业务中用户误删一条数据可能是很难恢复的。健康管理系统里还有一块特有功能统计图表。比如用户体检指标趋势图就用了ECharts来实现。Vue3里使用ECharts的常见做法是在组件销毁时调用chart.dispose()释放图表实例否则页面频繁切换时会出现内存泄漏。3.4 前端文件导出PDF的实现方案很多后台管理系统都有导出PDF、Excel的需求。这套系统里有一个体检报告PDF导出功能前端是把后端返回的HTML内容交给浏览器打印成PDF。后端用模板引擎将体检数据渲染为一个排版好的HTML页面前端通过iframe加载这个HTML再调用iframe的打印方法。这样一来PDF的排版完全由后端控制前端代码非常简洁。但如果数据量特别大比如要一次性导出几千条用户记录的Excel前端渲染就会卡顿。此时最佳实践是前端只需要向后端接口传递筛选条件由后端生成文件并返回下载链接前端用window.location.href downloadUrl触发下载。这样既保证了性能还减少了网络传输的体积。有经验的后端开发会在导出接口上做一层防重复提交因为用户在导出大量数据时等待时间较长可能会不停地点击导出按钮导致数据库压力过大。4. 微信小程序端从账号绑定到首页数据可视化的实现思路小程序端是普通用户接触系统的第一入口它的体验直接决定了用户愿不愿意持续使用这个健康管理工具。这一节重点讲几个小程序开发里必须掌握的细节微信登录流程、页面布局适配、组件间通信以及分包异步化的实际应用。4.1 微信登录与账号绑定的完整流程小程序的登录流程和传统Web登录完全不同。用户在Web端输入账号密码但小程序端用户不可能愿意去记一个账号密码尤其是一般健康管理App的目标人群还包括中老年人。微信生态下的标准做法是第一步小程序端调用wx.login()获取一个临时code。第二步把这个code通过后端接口传给SpringBoot服务。第三步后端拿着code去调用微信官方的https://api.weixin.qq.com/sns/jscode2session接口换取该用户唯一的openid。第四步后端查数据库里是否已存在这个openid如果不存在就自动创建一个默认账号存在则直接签发JWT返回给前端。第五步后续所有接口请求都带上这个JWT后端通过JWT解析出用户身份。这套流程里有个关键点我建议单独记一下拿到用户信息昵称、头像之后不要每次启动小程序都弹窗要求授权现在微信对用户隐私的管控越来越严格频繁获取用户信息很容易被封禁相关能力。项目里的方法是用户默认就是微信用户的昵称等用户主动进入我的页面去完善个人资料时再引导补充信息。4.2 首页健康指标卡片与数据展示首页是用户每次打开小程序最先看到的界面需要把用户最关心的核心健康指标展示出来。这个页面有两个核心难点一是数据的动态加载二是页面的布局适配。数据流上首页生命周期函数onShow里调一个聚合接口后端返回用户最新一次的体检记录信息包含血压、血糖、BMI这类关键指标。前端拿到结果后渲染到卡片上。这里要注意接口返回的时间字段是时间戳小程序端在WXML里没法直接做复杂格式化所以标准的做法是后端在返回时就把前端需要的展示格式算好比如signTime: 2025-01-15、isAbnormal: true前端只负责摆放位置。布局适配这个问题做小程序的人几乎都被坑过。不同的手机机型顶部导航栏高度不一样。iPhone X以后有刘海屏状态栏高度大约是44px普通安卓机是20px左右。如果用写死的CSS高度来布局很容易出现内容被刘海遮挡或者整体布局往下偏移的问题。推荐的做法// 适用微信小程序 const systemInfo wx.getSystemInfoSync() // 胶囊按钮位置信息 const menuButton wx.getMenuButtonBoundingClientRect() // 导航栏高度 胶囊顶部到状态栏底部的距离 * 2 胶囊高度 const navBarHeight (menuButton.top - systemInfo.statusBarHeight) * 2 menuButton.height这套系统在封装自定义导航栏时就是在app.js里先算好这些高度数据存到globalData里页面加载时直接读取使用省去了每个页面重复计算的麻烦。4.3 表单组件的选用单选、多选还是自定义选择器小程序里用户录入健康档案时会遇到很多选一项或者选多项的场景比如既往病史、过敏史、家族病史。微信小程序原生提供了picker组件它适合做那种点击后从底部弹起的滚筒选择器。但如果选项特别多比如既往病史可能有十几项甚至二十项滚动选择就太闹心了。这种场景我会优先选择用标签式多选一行展示若干个小标签用户直接点击选择选中状态用颜色区分。交互效率更高对不习惯滚动的中老年用户也更友好。对于必填项、选填项的区分在UI上要有明显标识。比如必填项用红色星号选填项则灰色提示。表单提交前必须做一次校验不符合规则的直接Toast提示不要等提交到后端再返回一堆错误信息浪费用户时间。这也是小程序端开发体验里最容易被低估的一个点——前端能拦住的错误坚决不要发给后端。4.4 分包异步化的实际使用场景随着项目功能越来越多小程序主包的体积很容易超过2MB的发布限制。这套健康管理系统在开发初期就考虑了分包把体检记录、健康档案这两个相对独立的功能拆到了子包中。分包带来的收益是主包体积减小小程序冷启动速度变快。而分包异步化则是微信小程序的一个进阶能力。传统分包的页面在使用其他分包的组件时必须把组件放到同一个包内否则会报错。通过分包异步化子包页面可以直接使用另一个子包的组件——小程序在编译时会把组件依赖关系记录下来运行时按需下载对应的分包。实际落地时我建议把公共的、体积较大的、使用频率低的图表组件放到一个独立的component分包里需要时再加载这样首屏体验会好很多。不过需要提醒的是分包异步化虽然好用但如果过度拆分会导致分包数量过多、碎片化严重反而拉低加载性能。一个原则是主包只放核心入口页和必要的基础库文件其他功能按业务域划分到各自的分包每个分包不要做得特别小避免几百K大小的模块满天飞。5. SQL脚本与数据库设计真正让系统跑起来的基石代码写得再好如果数据库表结构设计不合理项目一样是空中楼阁。这套系统的SQL脚本里包含了建库、建表、初始化数据三个部分拿到项目后先执行SQL脚本再启动后端接口才能正常返回数据。下面我重点讲一下表结构的设计思路和SQL脚本里值得借鉴的细节。5.1 核心表结构设计整套系统主要包含这几张核心表用户表是基础中的基础字段设计上除了常规的用户名、手机号、昵称以外要特别设计一个openid字段并且加上唯一索引。因为微信小程序的登录流程决定了同一用户有且只能有一个openid如果数据库里不限制唯一性就会出现重复账号的脏数据。体检记录表是业务核心其中体检结论、异常项建议用文本字段保存但为了便于统计需要设计一个风险等级字段比如1表示正常2表示轻度异常3表示明显异常。管理后台做数据筛选时直接按这个字段做等值查询比在文本里用like去模糊匹配效率高得多。体检明细表设计了指标名称、指标值、单位、参考范围下限、参考范围上限、是否异常等字段。这里有个设计细节是否异常这个字段不一定要在插入数据时手工指定。完全可以由后端在保存体检记录时自动比对指标值与参考范围后写入。这样数据库里存的永远是规范化的结果前端展示时不用做二次计算。5.2 SQL脚本的组织方式与初始化数据SQL脚本的顺序很讲究。先删表再建表是一般的惯例DROP TABLE IF EXISTS防止重复执行报错。再按照表之间的依赖关系来创建先创建无外键依赖的基础表比如用户表、角色表再创建业务表比如体检记录表、随访计划表。最后再插入初始化数据。你如果拿到这套系统的SQL脚本会发现里面会有一段初始化管理员账号的INSERT语句。这个是很实用的技巧——项目部署后不用你自己手动往数据库里塞管理员账号直接用一个预设账号密码登录系统。要注意的坑是初始化数据里的密码一定不能是明文这个脚本里对初始密码进行了BCrypt加密这也是Spring Security体系中主流的密码加密方案。5.3 MyBatis-Plus的使用与SQL编写注意事项项目的持久层框架用的是MyBatis-Plus它对单表的CRUD操作封装得非常到位日常开发中大多数接口都不用手写SQL直接继承BaseMapper就能获得selectById、selectPage、insert等基础方法。但对于多表关联查询尤其是报表统计类需求手写SQL还是最直接的方式。调试时有一个很关键的配置在application.yml里开启SQL日志打印开发环境能看到每个请求实际执行的SQL语句。排查接口数据不对之类的问题第一步就是看日志里的SQL到底是什么mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl另外要特别提醒字段命名的问题。数据库字段在项目里统一用下划线风格比如health_check_dateJava实体类用驼峰命名比如healthCheckDate。MyBatis-Plus默认开启了驼峰转换所以框架会自动映射但如果某个字段在实体类里命名不规范例如用了healthcheckdate这种全小写的写法映射就会失败接口返回null排查时特别容易忽略。这个坑我在接手别人的老项目时踩过不止一次。6. 前后端分离部署从本地到服务器的完整实操前后端分离项目的部署是一个完全独立于开发阶段的知识点。很多人在本地开发环境跑得好好的一到服务器部署就各种报错。这一节我把部署的完整流程和关键细节梳理一遍按照这个顺序操作能少走很多弯路。6.1 部署架构与核心原则本地开发时前端通过Vite的dev server运行在5173端口后端占8080端口两者之间有跨域问题所以开发环境用了Vite的proxy配置来做代理转发。在生产环境前端构建后生成的是静态文件HTML、CSS、JS这些文件直接交给Nginx托管后端接口依然是一个Java进程监听某个端口。关键是利用Nginx的reverse proxy特性把/api开头的请求转发到后端的Java服务上。这样对于浏览器来说所有请求都在同一个域名下不存在跨域问题。简化后的架构就是浏览器访问Nginx80端口→ Nginx托管前端静态文件 → 匹配到/api的请求转发到Java应用8080端口→ Java应用再访问MySQL3306端口。6.2 后端打包的坑与解决方案SpringBoot的打包方式很简单在项目根目录执行mvn clean package -DskipTests就会在target目录生成一个可执行的jar包。启动时用nohup java -jar health-manage.jar app.log 21 即可让应用在后台运行。这里要提醒几个常见的坑第一个坑是SpringBoot版本太高。很多新手从仓库拉下来的项目用的是最新的SpringBoot 3.x但本地JDK还是8或者11启动直接报错。SpringBoot 3.x强制要求JDK17及以上如果你的服务器还是JDK8就老老实实把SpringBoot版本降到2.7.x或者升级服务器的JDK。用这套系统的时候最好先看一眼项目的pom.xml里写的Java版本避免安装完环境才发现对不上。第二个坑是打包时jar包体积过大。SpringBoot默认用spring-boot-maven-plugin打成可执行jar里面包含了所有依赖比如一个简单项目也有50MB以上这很正常。不要试图把它拆成小jar包除非你很清楚自己在做什么。第三个坑是配置文件里写了本机地址。这个问题很容易踩——本地开发时数据库URL写的是localhost:3306生产环境的数据库一般不会和Java应用在同一台机器上。所以部署前一定要把application.yml里的数据库地址、用户名、密码改成生产环境的值。6.3 前端构建与Nginx配置前端构建命令很简单在项目根目录执行npm run buildVite会生成一个dist目录这个目录就是所有的静态文件。把dist目录下的所有文件上传到服务器的指定目录比如/usr/share/nginx/html/health然后在Nginx配置里添加一个server块指向它。关键的Nginx配置如下server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/health; index index.html; # 前端路由Vue Router的history模式需要这个配置 location / { try_files $uri $uri/ /index.html; } # 接口反向代理 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; } }try_files $uri $uri/ /index.html这个配置是Vue Router使用路由守卫后必须加的。如果不加用户在管理后台点击刷新按钮或者把某个路由地址分享给同事Nginx找不到对应的HTML文件就会返回404。加了这段配置后所有找不到的路径都会回归到index.html由前端路由接管。还有一点是HTTPS。小程序正式版要求所有请求域名必须配置在微信公众平台的合法域名里同时要求必须使用HTTPS。部署到生产环境时别忘了用SSL证书把HTTPS配上。如果只是学习阶段用开发者工具预览可以在开发者工具里勾选不校验合法域名来绕过限制。6.4 部署过程中最容易碰到的报错这段时间整理下来以下几个报错出现的频率最高启动Java应用时报端口被占用解决方案是先用netstat -tlnp | grep 8080找到占用进程kill -9掉再重新启动。或者更稳妥的方案是把Java应用的端口改掉比如放到8088。前端页面能打开但接口一直报500先不要急着去看Java日志。先确认Nginx配置里的proxy_pass有没有写对再确认Java应用有没有成功连接上数据库。很多时候是数据库的IP地址白名单没开被数据库服务端拒绝了。时间字段显示不对SpringBoot默认返回的日期格式是带T的ISO格式比如2025-01-15T10:30:00但前端想展示成YYYY-MM-DD HH:mm:ss。解决办法是在后端application.yml里配置一下Jackson的日期格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT87. 项目复现的完整路径与常见问题排查如果你拿到这套系统的代码想从头到尾跑起来我建议按照下面的顺序操作每一步确认没问题再进入下一步第一步检查环境。JDK版本、Maven版本、Node版本、MySQL版本都要先确认。项目里我默认用的是JDK8、MySQL5.7或8.0、Node16以上。环境不对后面哪里出问题都不奇怪。第二步初始化数据库。用Navicat或命令行工具执行SQL脚本确认所有表创建成功管理员账号存在。第三步启动后端。改好数据库连接配置执行mvn spring-boot:run或在IDE里直接运行启动类看到Started HealthApplication日志说明启动成功。然后用Postman或Apifox测试一个简单的接口比如登录接口能拿到Token就说明后端工作正常。第四步启动管理后台。执行npm install安装依赖然后npm run dev。很多人在这一步会遇到依赖安装慢的问题可以设置淘宝镜像源解决。启动后能打开登录页并成功登入管理后台说明前后端打通了。第五步启动小程序。用微信开发者工具导入小程序项目修改project.config.js里的appid为自己小程序的appid再把请求的baseUrl改成你本地的后端地址。开发者工具里勾选不校验合法域名以便本地联调。如果你在复现过程中遇到页面白屏的问题极大概率是接口请求失败。按F12打开调试面板看Network标签页里的请求状态一个一个排查。经常是后端接口返回了500但前端代码里没有做错误提示表现为页面卡在Loading状态。这就是为什么我在前端代码里统一封装了响应拦截器非200状态码一律Toast展示错误信息——排查问题的时候体验会好很多。另外一个常见的困惑是为什么代码一模一样在别人机器上能跑在我这就报错这个问题的答案大多数时候是版本不一致。Java的编译版本、Maven的仓库版本、Node依赖的lock文件版本一个字段对不上就可能引起莫名其妙的Bug。所以复现项目时尽量先用项目自带的工具版本配置跑通了再升级别上来就全用最新的。最后再分享一点我的实际体会做这种全栈项目最大的收获不是我写了一个能跑的系统而是通过完整地走一遍需求分析、表结构设计、接口开发、前端联调、应用部署把一个事情从头到尾吃透了。尤其是前后端分离项目真正难的不是某个单一技术点而是理解浏览器、前端工程、后端服务、数据库这几层之间是怎么协同工作的。我在做这套健康管理系统的时候最费心思的不是写代码本身而是理清业务关系谁可以看哪些数据、体检指标异常了怎么流转、健康提醒在什么条件下触发、随访任务如何闭环。这些抽象的业务规则最终变成数据库表字段、接口定义和前端状态。这个过程走通了后面再接手任何业务系统你都会觉得套路都差不多心里有底。如果你只是刚学完SpringBoot和Vue3的基础语法建议先别急着做那种图书管理学生管理的简单CRUD直接拿这种带完整业务链路的项目来练手收获会大得多。跑通之后试着改一两个需求比如给小程序加一个健康资讯栏目或者给后台加一个体检异常趋势分析图表改到自己满意为止。这种实战带来的经验是看再多教程都替代不了的。本文还有配套的精品资源点击获取