在校招季和毕业季，我经常被问到同一个问题：“智能瘦身系统”这个题目到底该怎么做？后台挂Java和SpringBoot，前端接小程序，名字还挂着“智能”和“健康”，听起来像是个健康类APP，可拿到题目之后很多人对着空目录无从下手。我前后帮两位朋友梳理过类似的题目，一个是“智能减肥小程序”，一个是“健康瘦身平台”，核心模块大同小异，踩过的坑也出奇一致。这篇就当作一份从零到一的拆解笔记，把需求分析、技术选型、后端设计、小程序实现、联调调试和论文材料整理串起来，按实际推进顺序写。1. 拆题目：智能瘦身系统真正要解决什么问题1.1 别把它当成“会算BMI的页面”很多人一看到“智能瘦身”就以为重点在算法，其实往届作品里真正惊艳的没几个，大部分能落地、能演示、能通过答辩的系统，本质都是一个“数据驱动的健康管理工具”。它的核心不是算出一个数字，而是围绕用户的身体数据、饮食记录、运动记录，持续地给出反馈和调整建议。所以拿到题目的第一件事，不是找算法，而是把业务闭环画清楚。这个系统至少要有三条主线：用户注册登录后，录入身高、体重、年龄、性别等基础信息，系统计算BMI、基础代谢率，生成当前身体状态评估。用户每天记录饮食和运动情况，小程序端负责快速录入，后端负责汇总卡路里，判断热量缺口是否合理。系统根据最新身体数据和近期记录，动态推荐下一餐的摄入建议、运动计划，并用图表展示体重和体脂变化趋势。这三条线一旦理清，项目从头到尾的模块边界就非常明确，论文的章节骨架也有了。你甚至可以提前跟导师沟通：这属于“行为干预类健康应用”，重点在数据闭环和交互体验，而不是推荐算法本身。1.2 两种角色与权限边界系统虽然叫“瘦身系统”，但大多数毕设和课设版本只需要两种角色：普通用户和管理员。普通用户在小程序端完成全部操作：登录注册、个人资料、身体数据录入、饮食记录、运动记录、查看报告、浏览系统推荐内容。管理员在后台网页端进行管理：用户列表、身体数据审核、食谱库与运动库维护、公告发布、基础数据统计。这里的“后台”一般做成一个独立的管理员Web端，复用同一套SpringBoot接口，只是前端形态不同。权限设计不复杂，但必须做。最简单的方案就是后端用拦截器拦截所有非登录请求，接口根据路径判断是否需要管理员角色，比如/admin/**就被限定为管理员权限。小程序的普通请求统一走/app/**前缀，后续加过滤逻辑就很清晰。1.3 数据流草图我习惯在写代码前先把数据流画出来，哪怕是随手在白板上画的箭头。这个项目里最核心的一条链路是：用户录入身体数据 → 后端按年龄性别等因子计算BMI和基础代谢 → 系统根据热量差目标生成当日摄入建议 → 用户记录三餐 → 后端汇总实际摄入 → 比对建议值，产生偏离提醒 → 一周后生成趋势报告。这条链路贯穿了后端接口设计、数据库表设计和小程序页面组织。你论文里的“系统功能模块图”和“数据流程图”，其实就是把这套逻辑画规范一点。2. 技术选型：SpringBoot+小程序+MySQL这套组合的来由2.1 后端为什么是SpringBoot这个题目绑定了Java和SpringBoot，可选项很清晰：Spring Boot负责Web接口，MyBatis-Plus负责数据库操作，MySQL存数据，Redis做缓存，JWT做登录令牌。为什么是这个组合，而不是更轻量的Node.js或者Flask？因为题目的定位是“可展示的完整工程”，SpringBoot在这类项目里有三个不可替代的好处：生态成熟，网上能找到大量教程和现成代码片段，开发效率和容错率都高。分层架构容易讲清楚，Controller、Service、Mapper三层拆解后，论文里的技术架构图顺手就能画出来。部署方式简单，内置Tomcat，打包成Jar包扔服务器上就能跑，答辩演示时候不用折腾复杂环境。版本方面建议选择SpringBoot 2.7.x这类相对稳定的版本，不要一上来追最新版。多数毕业设计类项目的依赖、插件和博客资料都基于2.x写就，遇到报错时搜索解决方案会省心很多。2.2 小程序端用原生还是跨端框架小程序前端有两条路：一条是用原生小程序语言，也就是结构上的WXML和样式文件，另一条是引入uni-app这类跨端框架，用Vue语法编写再编译到各个小程序平台。我的建议是：除非你对Vue非常熟，否则优先原生。理由是毕设项目页面数量不会太多，核心无非是首页、记录页、图表页、个人中心、登录注册这几块，原生足够应付。而且原生小程序调试工具对低版本兼容性处理更直接，代码结构也更贴近“小程序开发”这个题目本身。uni-app虽然写起来舒服，但一旦碰上框架版本和基础库版本不一致的怪问题，排查成本反而更高。2.3 数据库表设计：提前把“说话”的字段定好表结构是这个项目里最值得多花时间的地方，因为后面所有接口都建立在表之上。一张直觉合理的表，可以让开发效率翻倍；反之，后期改表结构几乎是灾难。核心表至少要包含以下几张：表名主要字段职责userid, openid, nickname, avatar, gender, phone用户基础信息body_recordid, user_id, height, weight, bmi, body_fat, record_date身体指标记录diet_recordid, user_id, food_name, calories, gram, meal_type, record_date饮食打卡记录exercise_recordid, user_id, exercise_name, duration, calories, record_date运动打卡记录food_libraryid, name, calories_per_100g, category, image管理员维护的食物库exercise_libraryid, name, calories_per_hour, description管理员维护的运动库plan_recommendid, user_id, plan_type, content, create_date系统给用户生成的建议记录需要注意的是，用户身体数据不要只存最新值，要按日期追加记录，这样后面的趋势折线图才有的画。体脂率在大多数小程序端没法直接测量，可以做成“用户手动填写，如果没有填则根据公式估算”的容错逻辑。2.4 登录认证：JWT比传统Session更适合小程序小程序端没有Cookie机制，Session管理相对麻烦，而JWT的思路是：用户登录成功后，后端返回一串携带用户信息的Token，小程序把Token存起来，后续每个请求都在Header里带上，后端解析Token即可识别用户。这是当前小程序类项目最主流的方案。JWT集成并不复杂，核心就三步：引入依赖，写一个登录接口生成Token，写一个拦截器解析Token。网上相关实现很多，但有一点容易踩坑：Token过期时间的处理。小程序的用户可能一周后才再次打开，过期时间如果设成30分钟会非常恼人。建议把Token有效期设置为7天甚至30天，并在拦截器里对过期Token返回特定状态码，小程序端拦截到后自动重新登录。3. 核心功能落地：从身体数据计算到智能推荐3.1 身体状态评估与基础代谢计算当用户录入身高和体重时，后端需要同步计算几个关键指标。BMI的公式是体重（kg）除以身高（m）的平方，这条大家都会，难点在于健康区间判断。系统里需要写入标准区间：18.5到23.9为正常，低于为偏瘦，24到27.9为超重，28以上为肥胖。这个标准在国内通用的成人标准上再稍作调整即可，不要写得太死，因为不同年龄段会有差异。基础代谢率可以用经典的Mifflin-St Jeor公式计算：男性：基础代谢 = 10 × 体重（kg） + 6.25 × 身高（cm） - 5 × 年龄 + 5女性：基础代谢 = 10 × 体重（kg） + 6.25 × 身高（cm） - 5 × 年龄 - 161用户每日标准摄入量再乘以活动系数，不常运动的人一般取1.2，每周运动3到5次取1.55。比如一个身高170cm、体重75kg、年龄24岁的男性，基础代谢大约为1710大卡左右，乘以1.2后约2052大卡，这就是维持当前体重的每日摄入参考。想要减脂，建议每日制造300到500大卡的热量缺口，在推荐摄入值里直接减400大卡作为目标线。3.2 饮食记录与热量汇总饮食记录页面是用户每天打开次数最多的功能，交互必须够快。用户在输入框里搜索食物名称，匹配到食物库后直接选择克数，热量自动计算。食物库里的基础数据用100克可食部分的热量存，库表结构上把“单位”明确标注为克，避免前端再换算。热量汇总要按日期拆分。后端提供按时间区间查询的接口，返回当日早中晚餐以及加餐分别摄入多少热量、总摄入多少。这里的SQL注意用GROUP BY meal_type做归类汇总，不要一次查几百条记录再在内存里循环相加，虽然数据量不大效果差不多，但后者的写法在接口性能上不优雅，答辩时也容易被追问。3.3 “智能推荐”不等于算法，而是规则引擎很多同学卡在“智能”这两个字上，觉得必须用机器学习模型。可实际上，一个让人信服的瘦身推荐功能，用规则就能跑通。规则引擎的思路是：根据用户最新的BMI和基础代谢值，判断当前状态属于偏瘦、正常、超重还是肥胖，不同状态对应不同的饮食结构调整策略。根据用户今日已摄入热量和今日目标热量，计算剩余可摄入范围，再推荐相应总热量范围的食物组合。根据用户最近7天的运动记录，如果运动量不足，则推荐入门级燃脂运动方案；如果稳步提升，则推荐加时长或换动作。这套规则可以用一张recommend_rule配置表维护，每条规则包含条件字段和结论建议。后端写一个定时触发的推荐生成逻辑，用户打开推荐页时先从推荐记录表里取最新结果。这样的设计既符合“智能”的字面意思，也具备很好的可扩展性，论文里还能写出基于规则引擎的推荐模块设计，比直接写死逻辑好讲得多。3.4 趋势数据与可视化图表是这个项目最直观的加分项。体重趋势图、BMI变化图、每日摄入热量与消耗热量的对比柱状图，三者做出来，演示效果立竿见影。后端接口按时间区间返回一组数值，前端负责渲染曲线图。在数据库层面，body_record表每次身体数据的新增就是曲线上的一个点。要注意的是，图表接口返回的数据必须按“日期+物理序号”双重排序，否则用户不规律的录入顺序会直接导致折线图乱跳。小程序端图表使用canvas方式实现即可，不需要额外引入复杂的图标框架，自己封装一个简单的折线图组件反而更可控。4. 后端架构与关键接口设计4.1 包结构：按业务模块划分还是按技术分层划分SpringBoot项目的包结构直接决定后续开发的顺手程度。我推荐按照“技术分层 + 业务模块”混合的方式组织，既有清晰的通用目录，又有按功能拆分的子包。示例结构大致是：com.xxx.slim ├── common │ ├── result # 统一返回体 │ ├── exception # 全局异常处理 │ └── interceptor # 登录拦截器 ├── config # 配置类 ├── controller # 接口层 ├── service # 业务层 ├── mapper # 数据访问层 ├── entity # 数据库实体 ├── dto # 入参出参对象 └── utils # JWT、日期工具等实体、DTO和VO不要混用。数据库实体只负责映射表结构，接收前端参数的DTO可以比实体少几个字段，返回给前端的VO可以额外组装提示文本。这样做稍显麻烦，但接口文档好写，答辩时回答“参数校验怎么做”也更有底气。4.2 登录注册与异常拦截登录时序要提前设计好。以最常见的手机号+验证码方案为例：用户输入手机号后，后端生成验证码并缓存到Redis，设置5分钟有效，用户提交注册信息后后端比对验证码。验证通过就创建用户记录，同时返回Token。这里有一个容易疏忽的点：验证码接口一定要做频率限制，同一个手机号60秒内不能重复发送。最简单的做法是在Redis里也存一个“最近发送时间”的键，发送前置检查，否则容易被刷短信接口，这在答辩评审时算一个明显安全漏洞。配置好登录Token后，全局异常处理也必须跟上。所有异常统一返回自定义结构体，包括业务异常、参数校验异常、未知异常。这样小程序端收到错误时可以直接弹出提示，而不是看到一串英文堆栈，体验差距肉眼可见。4.3 接口风格与统一返回体所有接口的返回值统一为：{ "code": 200, "message": "success", "data": {} }对应的Java类可以非常精简，核心属性就是code、message、data，配合静态方法success()和fail()使用。接口路径上，小程序端全部使用/app/user/**、/app/diet/**这样带/app前缀的地址，后台管理端使用/admin/**前缀。拦截器里匹配这两个前缀做不同的权限校验，后续想加接口文档或者做日志记录都会很顺。关键接口清单可以参考下面这张表：模块接口说明用户POST /app/user/login手机号验证码登录用户PUT /app/user/profile修改个人资料身体数据POST /app/body/record新增一条身体记录身体数据GET /app/body/trend获取一段时间内的体重趋势饮食POST /app/diet/record新增饮食打卡饮食GET /app/diet/summary按日统计摄入热量运动POST /app/exercise/record新增运动打卡推荐GET /app/plan/daily获取今日推荐建议管理端GET /admin/user/list分页查询用户列表管理端POST /admin/food/save新增或修改食物库记录4.4 定时任务与统计报表管理员后台最常用的统计页是“近7日新增用户数”和“用户体重变化分布”。这类统计如果等管理员点开再实时算，MySQL并发稍高就会吃力。建议使用SpringBoot自带的@Scheduled注解写两个定时任务，每晚凌晨把整点统计数据写入一张统计汇总表，后台展示时只查这张表。定时任务的正确用法是加一个任务开关配置，生产环境默认开启，本地调试默认关闭。否则本地运行时定时任务一旦触发，会输出一堆无关日志，干扰调试。这个细节很小，但能让你在答辩现场省去很多麻烦。5. 小程序端实现要点与页面节奏5.1 页面结构：四个Tab页面怎么定小程序端采用底部Tab导航是标配，四个Tab分别是首页、记录、报告、我的。首页展示今日推荐和快捷入口，记录页承担饮食和运动打卡，报告页展示趋势图表，我的页面承载个人资料、意见反馈和退出登录。首页不要让用户做太多操作，核心就一件事：展示“今天还能吃多少”。以今日目标热量 - 已摄入热量 + 已消耗热量得到一个剩余热量值，用醒目的进度条展示，这是整个小程序使用频率最高的信息。记录页要保证新增记录入口在拇指最方便点击的位置，不要藏在右上角。5.2 请求封装与登录态管理小程序每个请求都要带上Token，因此在utils/request.js里封装统一请求是必须的。封装时至少考虑三点：请求头默认携带Authorization: Bearer xxx。响应非200时统一弹出轻提示。捕获到Token过期标志时，跳转到登录页并清理本地缓存。登录态的管理用全局变量加本地缓存相结合。小程序冷启动时先从缓存读取Token并调用/app/user/info校验有效性，有效则进入主流程，无效则跳转登录。这一条链路做好，用户就会觉得“打开即用”，体验接近成熟商业应用。5.3 图表与长列表的性能处理报告页的图表数据通常不会太多，但记录页的长列表会随着使用时间增长。列表渲染建议用分页接口，每页10条，上拉加载下一页。在WXML中给列表绑定key，避免整页重渲染。真机上页面卡顿多数是因为列表数据一次性加载太多，不是图表渲染慢。5.4 表单校验与体验细节饮食记录的克数和小数点输入要用数字键盘，身高体重的输入框注意限制小数位数。这些如果不处理，后端就会收到各种“110.5.5”之类的脏数据。小程序端的校验不能只靠后端兜底，前端先做一层合法值判断，填写异常时给明确的提示文案，否则用户以为是系统坏掉了。6. 联调与调试：文档里通常不会写的坑6.1 本地开发中的跨域问题SpringBoot作为后端默认不允许跨域访问，小程序开发工具虽然不会触发浏览器跨域限制，但如果你用H5页面调试后台管理端，就一定会遇到。解决办法是写一个WebMvcConfigurer的跨域配置类，允许本地调试来源即可。需要注意，allowedOriginPatterns不要设置成*，至少要把端口范围把控好，避免后端接口被任意网页调用。6.2 数据库连接与初始化数据项目交付时，数据库初始化脚本一定要完整。很多同学喜欢把建表语句和测试数据分开，但验收时往往只会导入一次init.sql。所以我建议把建库、建表、初始数据全部放到同一个SQL脚本里，按顺序执行即可。食物库的初始数据建议至少包含50条常见的食物记录，覆盖主食、肉蛋奶、蔬菜水果、零食饮品几大类，这样演示时搜索任何品类都有结果，不会当场露怯。6.3 接口联调时的典型报错排查联调阶段最常遇到的几个问题，我按出现频率列一下：请求报401，排查Token有没有带上，或者Token是否为过期。请求传了JSON数据，但后端实体接收为null，排查Content-Type是否是application/json。数据插入成功但列表查不到，排查查询条件里是否多传了userID参数。日期字段显示“少一天”或“多一天”，排查JSON序列化和时区配置是否一致。排查时不要在小程序端瞎试，直接把请求地址复制到接口调试工具里发一次，看后端返回的原始报文和后端控制台日志，定位会快得多。后端日志一定要打印出请求参数和响应状态码，这一步会让你联调效率提升一半。6.4 小程序端真机预览与常用日志开发工具里的模拟器表现和真机存在差异，尤其是网络请求。真机预览前确认两点：后端接口地址要改成局域网IP或者服务器域名，不能是本地localhost；如果后端部署在服务器，接口允许的来源要加上对应域名。调试真机日志可以通过小程序开发工具的“真机调试”窗口查看，出现白屏或请求失败时第一反应先看这个窗口的报错，而不是反复重新扫码预览。7. 论文、调试文档和讲解材料的组织思路7.1 论文结构怎么定这个项目的论文结构其实可以很自然地套用软件开发流程：绪论、相关技术介绍、需求分析、总体设计、详细设计与实现、系统测试、总结。每一章的内容都和前面的开发步骤对应，唯一要注意的是不要把论文写成代码说明书的翻译版。需求分析部分重点写用例图和用例描述，讲清楚两类用户分别能做什么。总体设计部分给出系统功能架构图、技术架构图、数据库ER图。详细设计部分挑选三到四个核心功能模块展开，比如身体数据管理、饮食记录、推荐模块、后台管理，每个模块述流程、画时序图、展示关键代码节选和界面截图。7.2 图表和测试数据怎么准备论文里的图表要提前留时间整理，不要等写完代码再截图。最常用的几张图：系统功能模块树状图。后端三层架构结构图。用户登录的时序图。饮食热量汇总的业务流程图。关系数据库ER图。测试数据一定要真实连续。论文里如果出现一周的体重曲线，数据就应该是连续七天都有记录，不要出现周一到周三有，周四断档，周五又出现的情况。可以在本地写一个简单的数据生成逻辑，按时间顺序插入一组贴近真实减肥趋势的数据，比如初期体重逐步下降、中间有一到两天平台期，这样的演示效果非常可信。7.3 调试文档和演示讲解的侧重点调试文档不要求多细致，但必须能让人照着复现。一个小技巧是：把“从导入SQL脚本到启动后端、再到小程序扫码预览”这一整条流程，在另一台干净的电脑上完整跑一遍，把所有需要手动改的数据库密码、端口、地址全部记录下来。这样形成的调试文档就是实用的，不会漏掉默认密码或者路径配置这类致命细节。讲解讲解的时候，不需要讲每个功能，建议准备一条10分钟的演示路径：先展示注册登录，再录一次身体数据并计算BMI，接着模拟记录一顿午餐，系统因此更新了今日剩余热量，然后查看报告页的趋势图，最后打开后台管理端展示用户列表和食物库。这条路覆盖了业务全链路，评审能看明白，你也能讲清楚每一处设计原因。我把这个流程走完过好几遍，整体感受是：这类“基于Java+SpringBoot+小程序”的系统，真正的难度从来不是某个独立技术点，而是把用户数据采集、业务规则判断、前端交互反馈和后台管理职责串成一条完整链条。如果你正在做类似的题目，建议先花两三天把表结构和核心接口定清楚，后面写代码的速度会远超你的预期。
在校招季和毕业季，我经常被问到同一个问题：“智能瘦身系统”这个题目到底该怎么做？后台挂Java和SpringBoot，前端接小程序，名字还挂着“智能”和“健康”，听起来像是个健康类APP，可拿到题目之后很多人对着空目录无从下手。我前后帮两位朋友梳理过类似的题目，一个是“智能减肥小程序”，一个是“健康瘦身平台”，核心模块大同小异，踩过的坑也出奇一致。这篇就当作一份从零到一的拆解笔记，把需求分析、技术选型、后端设计、小程序实现、联调调试和论文材料整理串起来，按实际推进顺序写。1. 拆题目：智能瘦身系统真正要解决什么问题1.1 别把它当成“会算BMI的页面”很多人一看到“智能瘦身”就以为重点在算法，其实往届作品里真正惊艳的没几个，大部分能落地、能演示、能通过答辩的系统，本质都是一个“数据驱动的健康管理工具”。它的核心不是算出一个数字，而是围绕用户的身体数据、饮食记录、运动记录，持续地给出反馈和调整建议。所以拿到题目的第一件事，不是找算法，而是把业务闭环画清楚。这个系统至少要有三条主线：用户注册登录后，录入身高、体重、年龄、性别等基础信息，系统计算BMI、基础代谢率，生成当前身体状态评估。用户每天记录饮食和运动情况，小程序端负责快速录入，后端负责汇总卡路里，判断热量缺口是否合理。系统根据最新身体数据和近期记录，动态推荐下一餐的摄入建议、运动计划，并用图表展示体重和体脂变化趋势。这三条线一旦理清，项目从头到尾的模块边界就非常明确，论文的章节骨架也有了。你甚至可以提前跟导师沟通：这属于“行为干预类健康应用”，重点在数据闭环和交互体验，而不是推荐算法本身。1.2 两种角色与权限边界系统虽然叫“瘦身系统”，但大多数毕设和课设版本只需要两种角色：普通用户和管理员。普通用户在小程序端完成全部操作：登录注册、个人资料、身体数据录入、饮食记录、运动记录、查看报告、浏览系统推荐内容。管理员在后台网页端进行管理：用户列表、身体数据审核、食谱库与运动库维护、公告发布、基础数据统计。这里的“后台”一般做成一个独立的管理员Web端，复用同一套SpringBoot接口，只是前端形态不同。权限设计不复杂，但必须做。最简单的方案就是后端用拦截器拦截所有非登录请求，接口根据路径判断是否需要管理员角色，比如/admin/**就被限定为管理员权限。小程序的普通请求统一走/app/**前缀，后续加过滤逻辑就很清晰。1.3 数据流草图我习惯在写代码前先把数据流画出来，哪怕是随手在白板上画的箭头。这个项目里最核心的一条链路是：用户录入身体数据 → 后端按年龄性别等因子计算BMI和基础代谢 → 系统根据热量差目标生成当日摄入建议 → 用户记录三餐 → 后端汇总实际摄入 → 比对建议值，产生偏离提醒 → 一周后生成趋势报告。这条链路贯穿了后端接口设计、数据库表设计和小程序页面组织。你论文里的“系统功能模块图”和“数据流程图”，其实就是把这套逻辑画规范一点。2. 技术选型：SpringBoot+小程序+MySQL这套组合的来由2.1 后端为什么是SpringBoot这个题目绑定了Java和SpringBoot，可选项很清晰：Spring Boot负责Web接口，MyBatis-Plus负责数据库操作，MySQL存数据，Redis做缓存，JWT做登录令牌。为什么是这个组合，而不是更轻量的Node.js或者Flask？因为题目的定位是“可展示的完整工程”，SpringBoot在这类项目里有三个不可替代的好处：生态成熟，网上能找到大量教程和现成代码片段，开发效率和容错率都高。分层架构容易讲清楚，Controller、Service、Mapper三层拆解后，论文里的技术架构图顺手就能画出来。部署方式简单，内置Tomcat，打包成Jar包扔服务器上就能跑，答辩演示时候不用折腾复杂环境。版本方面建议选择SpringBoot 2.7.x这类相对稳定的版本，不要一上来追最新版。多数毕业设计类项目的依赖、插件和博客资料都基于2.x写就，遇到报错时搜索解决方案会省心很多。2.2 小程序端用原生还是跨端框架小程序前端有两条路：一条是用原生小程序语言，也就是结构上的WXML和样式文件，另一条是引入uni-app这类跨端框架，用Vue语法编写再编译到各个小程序平台。我的建议是：除非你对Vue非常熟，否则优先原生。理由是毕设项目页面数量不会太多，核心无非是首页、记录页、图表页、个人中心、登录注册这几块，原生足够应付。而且原生小程序调试工具对低版本兼容性处理更直接，代码结构也更贴近“小程序开发”这个题目本身。uni-app虽然写起来舒服，但一旦碰上框架版本和基础库版本不一致的怪问题，排查成本反而更高。2.3 数据库表设计：提前把“说话”的字段定好表结构是这个项目里最值得多花时间的地方，因为后面所有接口都建立在表之上。一张直觉合理的表，可以让开发效率翻倍；反之，后期改表结构几乎是灾难。核心表至少要包含以下几张：表名主要字段职责userid, openid, nickname, avatar, gender, phone用户基础信息body_recordid, user_id, height, weight, bmi, body_fat, record_date身体指标记录diet_recordid, user_id, food_name, calories, gram, meal_type, record_date饮食打卡记录exercise_recordid, user_id, exercise_name, duration, calories, record_date运动打卡记录food_libraryid, name, calories_per_100g, category, image管理员维护的食物库exercise_libraryid, name, calories_per_hour, description管理员维护的运动库plan_recommendid, user_id, plan_type, content, create_date系统给用户生成的建议记录需要注意的是，用户身体数据不要只存最新值，要按日期追加记录，这样后面的趋势折线图才有的画。体脂率在大多数小程序端没法直接测量，可以做成“用户手动填写，如果没有填则根据公式估算”的容错逻辑。2.4 登录认证：JWT比传统Session更适合小程序小程序端没有Cookie机制，Session管理相对麻烦，而JWT的思路是：用户登录成功后，后端返回一串携带用户信息的Token，小程序把Token存起来，后续每个请求都在Header里带上，后端解析Token即可识别用户。这是当前小程序类项目最主流的方案。JWT集成并不复杂，核心就三步：引入依赖，写一个登录接口生成Token，写一个拦截器解析Token。网上相关实现很多，但有一点容易踩坑：Token过期时间的处理。小程序的用户可能一周后才再次打开，过期时间如果设成30分钟会非常恼人。建议把Token有效期设置为7天甚至30天，并在拦截器里对过期Token返回特定状态码，小程序端拦截到后自动重新登录。3. 核心功能落地：从身体数据计算到智能推荐3.1 身体状态评估与基础代谢计算当用户录入身高和体重时，后端需要同步计算几个关键指标。BMI的公式是体重（kg）除以身高（m）的平方，这条大家都会，难点在于健康区间判断。系统里需要写入标准区间：18.5到23.9为正常，低于为偏瘦，24到27.9为超重，28以上为肥胖。这个标准在国内通用的成人标准上再稍作调整即可，不要写得太死，因为不同年龄段会有差异。基础代谢率可以用经典的Mifflin-St Jeor公式计算：男性：基础代谢 = 10 × 体重（kg） + 6.25 × 身高（cm） - 5 × 年龄 + 5女性：基础代谢 = 10 × 体重（kg） + 6.25 × 身高（cm） - 5 × 年龄 - 161用户每日标准摄入量再乘以活动系数，不常运动的人一般取1.2，每周运动3到5次取1.55。比如一个身高170cm、体重75kg、年龄24岁的男性，基础代谢大约为1710大卡左右，乘以1.2后约2052大卡，这就是维持当前体重的每日摄入参考。想要减脂，建议每日制造300到500大卡的热量缺口，在推荐摄入值里直接减400大卡作为目标线。3.2 饮食记录与热量汇总饮食记录页面是用户每天打开次数最多的功能，交互必须够快。用户在输入框里搜索食物名称，匹配到食物库后直接选择克数，热量自动计算。食物库里的基础数据用100克可食部分的热量存，库表结构上把“单位”明确标注为克，避免前端再换算。热量汇总要按日期拆分。后端提供按时间区间查询的接口，返回当日早中晚餐以及加餐分别摄入多少热量、总摄入多少。这里的SQL注意用GROUP BY meal_type做归类汇总，不要一次查几百条记录再在内存里循环相加，虽然数据量不大效果差不多，但后者的写法在接口性能上不优雅，答辩时也容易被追问。3.3 “智能推荐”不等于算法，而是规则引擎很多同学卡在“智能”这两个字上，觉得必须用机器学习模型。可实际上，一个让人信服的瘦身推荐功能，用规则就能跑通。规则引擎的思路是：根据用户最新的BMI和基础代谢值，判断当前状态属于偏瘦、正常、超重还是肥胖，不同状态对应不同的饮食结构调整策略。根据用户今日已摄入热量和今日目标热量，计算剩余可摄入范围，再推荐相应总热量范围的食物组合。根据用户最近7天的运动记录，如果运动量不足，则推荐入门级燃脂运动方案；如果稳步提升，则推荐加时长或换动作。这套规则可以用一张recommend_rule配置表维护，每条规则包含条件字段和结论建议。后端写一个定时触发的推荐生成逻辑，用户打开推荐页时先从推荐记录表里取最新结果。这样的设计既符合“智能”的字面意思，也具备很好的可扩展性，论文里还能写出基于规则引擎的推荐模块设计，比直接写死逻辑好讲得多。3.4 趋势数据与可视化图表是这个项目最直观的加分项。体重趋势图、BMI变化图、每日摄入热量与消耗热量的对比柱状图，三者做出来，演示效果立竿见影。后端接口按时间区间返回一组数值，前端负责渲染曲线图。在数据库层面，body_record表每次身体数据的新增就是曲线上的一个点。要注意的是，图表接口返回的数据必须按“日期+物理序号”双重排序，否则用户不规律的录入顺序会直接导致折线图乱跳。小程序端图表使用canvas方式实现即可，不需要额外引入复杂的图标框架，自己封装一个简单的折线图组件反而更可控。4. 后端架构与关键接口设计4.1 包结构：按业务模块划分还是按技术分层划分SpringBoot项目的包结构直接决定后续开发的顺手程度。我推荐按照“技术分层 + 业务模块”混合的方式组织，既有清晰的通用目录，又有按功能拆分的子包。示例结构大致是：com.xxx.slim ├── common │ ├── result # 统一返回体 │ ├── exception # 全局异常处理 │ └── interceptor # 登录拦截器 ├── config # 配置类 ├── controller # 接口层 ├── service # 业务层 ├── mapper # 数据访问层 ├── entity # 数据库实体 ├── dto # 入参出参对象 └── utils # JWT、日期工具等实体、DTO和VO不要混用。数据库实体只负责映射表结构，接收前端参数的DTO可以比实体少几个字段，返回给前端的VO可以额外组装提示文本。这样做稍显麻烦，但接口文档好写，答辩时回答“参数校验怎么做”也更有底气。4.2 登录注册与异常拦截登录时序要提前设计好。以最常见的手机号+验证码方案为例：用户输入手机号后，后端生成验证码并缓存到Redis，设置5分钟有效，用户提交注册信息后后端比对验证码。验证通过就创建用户记录，同时返回Token。这里有一个容易疏忽的点：验证码接口一定要做频率限制，同一个手机号60秒内不能重复发送。最简单的做法是在Redis里也存一个“最近发送时间”的键，发送前置检查，否则容易被刷短信接口，这在答辩评审时算一个明显安全漏洞。配置好登录Token后，全局异常处理也必须跟上。所有异常统一返回自定义结构体，包括业务异常、参数校验异常、未知异常。这样小程序端收到错误时可以直接弹出提示，而不是看到一串英文堆栈，体验差距肉眼可见。4.3 接口风格与统一返回体所有接口的返回值统一为：{ "code": 200, "message": "success", "data": {} }对应的Java类可以非常精简，核心属性就是code、message、data，配合静态方法success()和fail()使用。接口路径上，小程序端全部使用/app/user/**、/app/diet/**这样带/app前缀的地址，后台管理端使用/admin/**前缀。拦截器里匹配这两个前缀做不同的权限校验，后续想加接口文档或者做日志记录都会很顺。关键接口清单可以参考下面这张表：模块接口说明用户POST /app/user/login手机号验证码登录用户PUT /app/user/profile修改个人资料身体数据POST /app/body/record新增一条身体记录身体数据GET /app/body/trend获取一段时间内的体重趋势饮食POST /app/diet/record新增饮食打卡饮食GET /app/diet/summary按日统计摄入热量运动POST /app/exercise/record新增运动打卡推荐GET /app/plan/daily获取今日推荐建议管理端GET /admin/user/list分页查询用户列表管理端POST /admin/food/save新增或修改食物库记录4.4 定时任务与统计报表管理员后台最常用的统计页是“近7日新增用户数”和“用户体重变化分布”。这类统计如果等管理员点开再实时算，MySQL并发稍高就会吃力。建议使用SpringBoot自带的@Scheduled注解写两个定时任务，每晚凌晨把整点统计数据写入一张统计汇总表，后台展示时只查这张表。定时任务的正确用法是加一个任务开关配置，生产环境默认开启，本地调试默认关闭。否则本地运行时定时任务一旦触发，会输出一堆无关日志，干扰调试。这个细节很小，但能让你在答辩现场省去很多麻烦。5. 小程序端实现要点与页面节奏5.1 页面结构：四个Tab页面怎么定小程序端采用底部Tab导航是标配，四个Tab分别是首页、记录、报告、我的。首页展示今日推荐和快捷入口，记录页承担饮食和运动打卡，报告页展示趋势图表，我的页面承载个人资料、意见反馈和退出登录。首页不要让用户做太多操作，核心就一件事：展示“今天还能吃多少”。以今日目标热量 - 已摄入热量 + 已消耗热量得到一个剩余热量值，用醒目的进度条展示，这是整个小程序使用频率最高的信息。记录页要保证新增记录入口在拇指最方便点击的位置，不要藏在右上角。5.2 请求封装与登录态管理小程序每个请求都要带上Token，因此在utils/request.js里封装统一请求是必须的。封装时至少考虑三点：请求头默认携带Authorization: Bearer xxx。响应非200时统一弹出轻提示。捕获到Token过期标志时，跳转到登录页并清理本地缓存。登录态的管理用全局变量加本地缓存相结合。小程序冷启动时先从缓存读取Token并调用/app/user/info校验有效性，有效则进入主流程，无效则跳转登录。这一条链路做好，用户就会觉得“打开即用”，体验接近成熟商业应用。5.3 图表与长列表的性能处理报告页的图表数据通常不会太多，但记录页的长列表会随着使用时间增长。列表渲染建议用分页接口，每页10条，上拉加载下一页。在WXML中给列表绑定key，避免整页重渲染。真机上页面卡顿多数是因为列表数据一次性加载太多，不是图表渲染慢。5.4 表单校验与体验细节饮食记录的克数和小数点输入要用数字键盘，身高体重的输入框注意限制小数位数。这些如果不处理，后端就会收到各种“110.5.5”之类的脏数据。小程序端的校验不能只靠后端兜底，前端先做一层合法值判断，填写异常时给明确的提示文案，否则用户以为是系统坏掉了。6. 联调与调试：文档里通常不会写的坑6.1 本地开发中的跨域问题SpringBoot作为后端默认不允许跨域访问，小程序开发工具虽然不会触发浏览器跨域限制，但如果你用H5页面调试后台管理端，就一定会遇到。解决办法是写一个WebMvcConfigurer的跨域配置类，允许本地调试来源即可。需要注意，allowedOriginPatterns不要设置成*，至少要把端口范围把控好，避免后端接口被任意网页调用。6.2 数据库连接与初始化数据项目交付时，数据库初始化脚本一定要完整。很多同学喜欢把建表语句和测试数据分开，但验收时往往只会导入一次init.sql。所以我建议把建库、建表、初始数据全部放到同一个SQL脚本里，按顺序执行即可。食物库的初始数据建议至少包含50条常见的食物记录，覆盖主食、肉蛋奶、蔬菜水果、零食饮品几大类，这样演示时搜索任何品类都有结果，不会当场露怯。6.3 接口联调时的典型报错排查联调阶段最常遇到的几个问题，我按出现频率列一下：请求报401，排查Token有没有带上，或者Token是否为过期。请求传了JSON数据，但后端实体接收为null，排查Content-Type是否是application/json。数据插入成功但列表查不到，排查查询条件里是否多传了userID参数。日期字段显示“少一天”或“多一天”，排查JSON序列化和时区配置是否一致。排查时不要在小程序端瞎试，直接把请求地址复制到接口调试工具里发一次，看后端返回的原始报文和后端控制台日志，定位会快得多。后端日志一定要打印出请求参数和响应状态码，这一步会让你联调效率提升一半。6.4 小程序端真机预览与常用日志开发工具里的模拟器表现和真机存在差异，尤其是网络请求。真机预览前确认两点：后端接口地址要改成局域网IP或者服务器域名，不能是本地localhost；如果后端部署在服务器，接口允许的来源要加上对应域名。调试真机日志可以通过小程序开发工具的“真机调试”窗口查看，出现白屏或请求失败时第一反应先看这个窗口的报错，而不是反复重新扫码预览。7. 论文、调试文档和讲解材料的组织思路7.1 论文结构怎么定这个项目的论文结构其实可以很自然地套用软件开发流程：绪论、相关技术介绍、需求分析、总体设计、详细设计与实现、系统测试、总结。每一章的内容都和前面的开发步骤对应，唯一要注意的是不要把论文写成代码说明书的翻译版。需求分析部分重点写用例图和用例描述，讲清楚两类用户分别能做什么。总体设计部分给出系统功能架构图、技术架构图、数据库ER图。详细设计部分挑选三到四个核心功能模块展开，比如身体数据管理、饮食记录、推荐模块、后台管理，每个模块述流程、画时序图、展示关键代码节选和界面截图。7.2 图表和测试数据怎么准备论文里的图表要提前留时间整理，不要等写完代码再截图。最常用的几张图：系统功能模块树状图。后端三层架构结构图。用户登录的时序图。饮食热量汇总的业务流程图。关系数据库ER图。测试数据一定要真实连续。论文里如果出现一周的体重曲线，数据就应该是连续七天都有记录，不要出现周一到周三有，周四断档，周五又出现的情况。可以在本地写一个简单的数据生成逻辑，按时间顺序插入一组贴近真实减肥趋势的数据，比如初期体重逐步下降、中间有一到两天平台期，这样的演示效果非常可信。7.3 调试文档和演示讲解的侧重点调试文档不要求多细致，但必须能让人照着复现。一个小技巧是：把“从导入SQL脚本到启动后端、再到小程序扫码预览”这一整条流程，在另一台干净的电脑上完整跑一遍，把所有需要手动改的数据库密码、端口、地址全部记录下来。这样形成的调试文档就是实用的，不会漏掉默认密码或者路径配置这类致命细节。讲解讲解的时候，不需要讲每个功能，建议准备一条10分钟的演示路径：先展示注册登录，再录一次身体数据并计算BMI，接着模拟记录一顿午餐，系统因此更新了今日剩余热量，然后查看报告页的趋势图，最后打开后台管理端展示用户列表和食物库。这条路覆盖了业务全链路，评审能看明白，你也能讲清楚每一处设计原因。我把这个流程走完过好几遍，整体感受是：这类“基于Java+SpringBoot+小程序”的系统，真正的难度从来不是某个独立技术点，而是把用户数据采集、业务规则判断、前端交互反馈和后台管理职责串成一条完整链条。如果你正在做类似的题目，建议先花两三天把表结构和核心接口定清楚，后面写代码的速度会远超你的预期。