先交代项目背景。这个系统不是拍脑袋想的是我在日常和几个健身房朋友聊天时发现的需求大多数人不是不想吃得健康而是不知道自己每天该吃多少、吃了什么、缺了什么光靠“少吃多动”四个字根本没法落地。所以我干脆做了一个前后端分离的健康饮食数据管理系统记录一日三餐自动算热量和营养素结合个人档案给推荐食谱用图表把趋势摆出来让饮食管理从“凭感觉”变成“看数据”。技术栈很明确后端Spring Boot前端Vue3前后端通过RESTful API交互。项目既有业务逻辑复杂度又覆盖了JWT鉴权、定时任务、数据可视化、文件上传这些常见企业级开发场景用来做毕设、个人作品集或者内部小工具都很合适。1. 项目整体设计与技术选型思路1.1 系统到底解决什么问题先想清楚一件事这个系统不是为了“做个管理系统”而做它的核心使用场景是个人日常饮食记录与健康管理。用户注册登录后需要录入自己的身高、体重、年龄、运动频率、健康目标系统根据这些信息算出每日热量需求再结合食材库给出三餐搭配用户每天记录实际吃进去的食物系统自动汇总热量和三大营养素生成日报和周报通过ECharts展示变化曲线。管理员端还能维护食材库、查看用户健康档案、推送健康提醒。从需求层次看这个项目包含了典型的增删改查、权限控制、业务状态流转、定时统计、数据可视化这五类核心功能任何一个后端开发项目都逃不开这五类问题。把这类问题吃透换任何业务场景都能快速上手。1.2 为什么是Spring Boot加Vue3而不是别的选型的时候我做过对比。后端如果继续用传统的SSM加JSP模板渲染开发效率太低前后端代码混在一起分工和部署都麻烦用Spring Boot就清爽很多内置Tomcat、自动配置、生态成熟Spring Security或者JWT都有现成方案。前端在Vue2、Vue3和React之间我最后选了Vue3加TypeScript加Vite原因是组合式API写业务逻辑更聚合TypeScript对复杂数据结构的约束能力很强Vite冷启动和热更新体验比Webpack好一截。这套组合在中小型管理系统里已经是事实标准教程多、坑少、招人也好招。前后端分离带来一个额外收益后端按接口维度提供服务不同前端可以同时对接。我后期就把管理后台和用户端做成了两个独立页面入口共用一套后端API前端只通过路由和权限标识区分身份。如果以后要做小程序后端可以完全复用。1.3 工程初始化与目录结构规划后端我用的是Maven多模块思想但没强行拆微服务保持单应用多包结构。包名按功能划分controller、service、mapper、entity、dto、vo、config、common、utils。controller只做参数接收和结果包装业务逻辑全部下沉到service层mapper层用MyBatis-Plus的BaseMapper复杂的联表统计写在XML里。项目创建时我建议直接用Spring Initializr选Spring Boot 3.xJDK用17Java EE包名已经从javax变成jakarta这个细节很多人容易踩坑。前端用create-vite脚手架初始化目录按views、components、composables、router、stores、api、utils、types划分。views放页面级组件components放可复用的UI组件composables放组合式函数stores放Pinia状态api里统一放请求方法。这套结构维护起来非常顺手定位问题基本不需要猜。2. 核心功能拆解与数据模型设计2.1 功能模块全景图系统按角色分两类功能。普通用户端包括个人健康档案管理、每日饮食记录、智能食谱推荐、营养摄入统计、历史趋势图表、健康提醒。管理员端包括食材库管理、用户管理、膳食方案管理、系统数据统计。其中营养摄入统计涉及实时计算食物记录保存后要同步更新当天汇总数据这是核心链路。还有一个容易被忽略的点健康提醒模块。我实现的是检查用户最近三天的蔬菜水果摄入量如果低于阈值就生成一条提醒提示用户增加膳食纤维摄入。这类规则虽然简单但让系统的“智能感”提升非常明显。2.2 数据库表设计的核心表数据库我用的是MySQL 8.0数据库名health_food。主要表如下user是用户账号表字段有id、username、password存BCrypt加密后的密文、nickname、avatar存文件路径、role、status、create_time、update_time。user_profile是用户健康档案表保存height_cm、weight_kg、birth_date、gender、activity_level活动系数、goal减脂、增肌、维持、target_weight每次体重更新都插入一条新记录而不是覆盖这样能保留体重趋势数据。food是食材库表记录食物名称、分类主食、肉类、蔬菜、水果、奶制品等、每100克的热量千卡、蛋白质克、脂肪克、碳水化合物克、膳食纤维克。meal_plan是每日推荐膳食计划表包含user_id、plan_date、meal_type早餐、午餐、晚餐、加餐、food_id、amount_g克数、total_calories。meal_record是用户实际饮食记录表结构类似meal_plan但多一个record_time字段记录的是真实摄入。nutrient_report是每日营养汇总表保存某一天的总热量和三大营养素数据由定时任务从meal_record聚合生成。这里有个设计心得用户档案为什么要单独拆表而不是直接放user表因为档案是动态的体重、目标、活动系数会变化拆开之后保留历史记录后面做趋势分析和推荐算法时数据会更准确。同理食材库和膳食方案分开是为了让管理员维护食物基础数据时不影响套餐推荐逻辑。2.3 营养计算的算法设计这个模块是整个系统最核心的部分我花了不少时间整理公式。每日热量需求用Mifflin-St Jeor公式计算基础代谢率BMR男性BMR等于10乘以体重公斤加6.25乘以身高厘米减5乘以年龄加5女性BMR等于10乘以体重加6.25乘以身高减5乘以年龄减161然后用BMR乘以活动系数得到每日总消耗热量TDEE。活动系数从1.2到1.725分四档对应久坐、轻度活动、中度活动、高强度运动。举个例子一个25岁女性身高165厘米体重60公斤每周运动1到3天属于轻度活动算下来BMR是1345千卡左右TDEE约1850千卡。如果目标是减脂每天制造300到500千卡热量缺口推荐摄入控制在1350到1550千卡之间。三大营养素分配上蛋白质按每公斤体重1.2到1.5克算脂肪每公斤0.8到1.0克剩下的热量分配给碳水化合物。按这个逻辑推出来这个用户每日蛋白质约90克360千卡脂肪约54克486千卡碳水约150克600千卡左右加起来就是合理的热量预算。这套算法虽然不算复杂但至少有科学公式支撑比那些单纯“少吃多动”的建议可信很多。在实现时我把底层公式封装成一个独立的NutritionCalculator工具类输入用户档案和食材列表输出每日膳食方案这样接口层只负责参数转换业务逻辑随时可复用也方便后面扩展。3. 后端Spring Boot关键实现与实战细节3.1 工程搭建与依赖选型后端我用的Spring Boot 3.2.2JDK17核心依赖是Spring Web、MyBatis-Plus、MySQL驱动、Redis、Lombok、Hutool、JWT用jjwt库。MyBatis-Plus版本必须适配Spring Boot 3starter名称是mybatis-plus-spring-boot3-starter注意版本不要用旧的2.x。Redis不是必须的但我在用户登录token缓存和食材热榜统计上用到了效果不错。application.yml里有一个关键配置值得单独说就是自动建表。我用的是MySQL的createDatabaseIfNotExist参数加Spring的SQL初始化脚本spring: datasource: url: jdbc:mysql://localhost:3306/health_food?createDatabaseIfNotExisttrueuseUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: yourpassword sql: init: mode: always schema-locations: classpath:sql/schema.sqlschema.sql里全部用CREATE TABLE IF NOT EXISTS写建表语句这样项目首次启动时会自动创建数据库和表后边重启也不会报错。这个配置在团队开发时非常实用——新同事拉代码后不需要手动执行SQL脚本启动项目就自动完成初始化。要注意的是spring.sql.init默认只在嵌入式数据源生效MySQL需要手动设置mode为always。3.2 统一响应体与全局异常处理接口返回格式如果各写各的前端联调会相当痛苦。我在common包定义了一个Result类统一返回code、message、data三段式结构成功code为200失败code为500业务异常code为自定义错误码。所有Controller接口都返回Result对象配合全局异常处理器代码里基本不用写try-catch。Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT result new Result(); result.code 200; result.message success; result.data data; return result; } public static T ResultT error(String message) { ResultT result new Result(); result.code 500; result.message message; return result; } }全局异常处理用RestControllerAdvice加ExceptionHandler注解分别处理业务异常BusinessException、参数校验异常MethodArgumentNotValidException、兜底异常Exception。好处是业务代码里可以放心用throw new BusinessException(食材不存在)前端拿到的永远是结构统一的错误信息。排查问题时日志也好查异常栈都打在统一的地方。3.3 JWT登录鉴权与拦截器登录方案我没有用Spring Security因为项目体量不大引入Security后配置成本偏高很多新手会被默认的登录页和安全过滤链搞晕。我直接用JWT加HandlerInterceptor实现逻辑清晰代码量少。登录接口校验用户名密码成功后用jjwt生成token把userId和role存进token的claims里过期时间设置24小时返回给前端。前端每次请求在Authorization头带Bearer token后端拦截器解析校验。拦截器里要注意放行白名单登录接口、注册接口、静态资源路径、错误页面都需要排除。用户端和管理员端的权限区分我用角色字段role来判断管理员接口的拦截器里额外校验role是否等于admin。token过期时拦截器返回401状态码前端axios拦截器收到401自动跳转登录页这个链条我在第四章讲前端的时候会细说。3.4 定时任务与数据汇总每天凌晨零点系统要生成前一天所有用户的营养汇总报告这个需求用Spring的Scheduled注解实现单机应用足够可靠。我在配置类上加EnableScheduling在统计任务方法上加Scheduled(cron 0 0 1 * * ?)凌晨1点执行。任务逻辑是查出昨天的记录数据按用户分组聚合热量、蛋白质、脂肪、碳水然后批量插入nutrient_report表。第一版上线后我发现一个问题如果凌晨1点用户还没睡正在补录昨天的饮食记录汇总数据就会出现偏差。后来我把统计时间改成凌晨3点并在用户补录时增加一个逻辑如果补录日期已经是历史日期就同步更新对应日期的汇总报告。这样虽然代码多写了几行但数据一致性好了很多。还有一个隐藏问题定时任务跑批处理时如果数据量大单线程执行耗时长会影响后续任务我用的方法是先查出来当天有记录的用户id列表再按用户循环聚合每个用户独立提交避免一个大事务锁太久。3.5 文件上传与图片回显用户头像和食物图片需要上传我采用的是本地磁盘存储方案。上传接口接收MultipartFile校验文件类型和后缀文件大小限制在5MB以内文件名用UUID重命名避免冲突存储路径通过配置文件注入。文件保存后返回相对路径前端展示图片时通过静态资源映射访问。映射配置是WebMvcConfigurer的addResourceHandlers方法将/web/upload/**映射到实际磁盘路径。生产环境如果要上云换成MinIO或者OSS就行接口层不用大改。这里有个经验上传文件的目录一定要提前创建好否则文件会写失败。我是在项目启动时用一个ApplicationRunner监听器判断目录是否存在不存在就创建杜绝了权限和路径问题。4. 前端Vue3实现要点4.1 项目初始化与核心依赖前端我用Vite创建Vue3工程模板选择vue-ts开发语言用TypeScript。核心依赖有Vue Router、Pinia、Axios、ECharts、Element Plus。Element Plus这个组件库非常契合后台管理系统的场景表格、表单、弹窗、日期选择器都能直接使用。npm create vitelatest health-food-web -- --template vue-ts cd health-food-web npm install npm install vue-router4 pinia axios echarts element-plus element-plus/icons-vueVite配置里重点做了开发代理前端开发服务器跑在5173端口后端接口跑在8080端口如果不配代理浏览器直接请求后端接口就会触发跨域问题。Vite的proxy配置非常简单server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端代码里所有请求都写/api开头开发时由Vite转发到后端生产环境部署时再用Nginx把/api路径反向代理到Java服务前后端联调阶段全程不用手工处理CORS头。4.2 axios统一封装与token管理axios请求封装在整个系统中扮演了很关键的角色。我把请求逻辑全部收敛到一个文件里统一处理请求头、超时时间、响应拦截、错误提示。请求拦截器从localStorage取出token并放到Authorization头响应拦截器判断HTTP状态码和业务code如果code不是200就弹出错误信息如果HTTP状态码是401就清除本地登录状态跳转登录页。const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) service.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.data }, error { if (error.response?.status 401) { localStorage.removeItem(token) router.push(/login) } else { ElMessage.error(error.response?.data?.message || 网络异常) } return Promise.reject(error) } )这里有个细节值得注意我在响应拦截器里返回的是res.data而不是res本身这样业务代码拿到的直接就是后端返回的业务数据不用每层都写.data.data清爽很多。4.3 组合式API与状态管理Vue3的组合式函数是我最喜欢用的组织方式。以健康报表页为例我把获取统计数据、筛选时间范围、加载状态、错误处理全部封装到一个useHealthReport函数里页面组件只需要调用这个函数就能拿到所需的响应式数据和方法组件模板干净逻辑还方便复用如果后台管理端也要看报表直接引用同一个组合式函数就行。Pinia管理登录用户信息和系统全局状态。user store保存token、用户信息、角色、菜单权限登录成功时调用setUserInfo方法写入状态。由于刷新页面后Pinia数据会丢失我设计了一个初始化逻辑页面加载时从localStorage读取用户信息并重新填充store同时调用接口校验token是否有效。这个“本地缓存加接口校验”的组合体验最好刷新页面不会闪白屏token失效也能第一时间被前端感知。4.4 数据可视化图表的实现细节营养摄入趋势和体重变化趋势用的是ECharts。ECharts体积大按需引入是必须的。我建立了一个独立的echarts.ts文件手动注册需要用到的图表组件LineChart、PieChart、BarChart以及对应的TitleComponent、TooltipComponent、GridComponent、LegendComponent。页面使用时直接从封装好的initChart函数获取实例避免整个组件库打包进主文件。营养摄入概览我采用了环形图展示碳水、蛋白质、脂肪的占比和实际克数环形图视觉冲击力强用户扫一眼就知道今天哪里吃超标了。七日热量趋势用折线图x轴是日期y轴是千卡再加一条标准线表示每日推荐热量曲线在标准线上方就说明吃多了。这个标准线我用ECharts的markLine实现不用后端再单独返回对比数据。5. 常见问题与排查实录5.1 LocalDateTime序列化问题前后端联调时最经典的问题是时间格式。Java 8的LocalDateTime默认序列化成数组前端拿到的是[2025, 6, 18, 14, 30, 0]这种结构没法直接用。我的解决方法是全局配置Jackson关闭时间戳统一时间格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同时给前端约定所有时间字段都已格式化好的字符串前端不需要再做任何处理。如果某些字段需要单独格式就在实体类字段上加JsonFormat(pattern yyyy-MM-dd)注解。5.2 MyBatis-Plus自动建表踩坑记录MyBatis-Plus本身没有建表功能我用的是Spring SQL初始化。这里有两个坑值得说第一schema.sql里不能写DROP TABLE否则每次启动数据都被清空线上环境直接崩。第二MySQL 8默认字符集不是utf8mb4如果建表语句不指定存emoji或者生僻字会报错。我最终在建表语句里统一加ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci彻底避免编码问题。5.3 前后端跨域与404问题开发阶段用Vite代理基本不会遇到跨域但生产环境部署时如果前端和后端不在同一个域Nginx配置是关键。前端静态文件由Nginx托管/api路径代理到后端服务server { listen 80; server_name yourdomain.com; location / { root /opt/health-food-web/dist; index index.html; 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; } }try_files那行是解决Vue Router history模式刷新404的关键一定不能漏。5.4 营养摄入统计不准确的排查有段时间用户反馈日报数据和记录对不上排查后发现是时区问题。MySQL连接串里serverTimezoneAsia/Shanghai配了但JVM默认时区是UTC定时任务执行时用LocalDate.now()取日期取到的是UTC的日期和北京时间差了8小时导致凌晨统计时把前一天的记录分到了两天里。解决方案是应用启动类上设置PostConstruct里修改默认时区或者启动命令加-Duser.timezoneGMT8。这个问题非常隐蔽没有日志对比很难发现建议在表里存datetime字段时额外加一个日期冗余字段统计时直接用时间范围查询。5.5 前端动态权限与刷新白屏管理端菜单是根据角色动态加载的早期用前端路由守卫判断角色刷新页面后由于store里角色信息丢失路由表构建失败导致白屏。后来我把用户信息和角色持久化到localStorage应用初始化时先解析token再加载用户信息最后才渲染路由。整个过程用Pinia的store初始化方法串联在main.ts里await store.init()后再mount应用。这样刷新再也不会白屏。最后再分享一点实际运营中的经验系统做完之后我给自己用了一段时间发现很多人记录饮食坚持不下去的原因是手动输入太麻烦。我后来在食材库里加了搜索联想和常用食材置顶用户选择食材时不用翻几十页找直接搜“鸡胸肉”就能出现常用选项。这个改动看起来不大但实际使用频率极高。另外一个体会是不要试图替代专业医生或营养师。我在系统里做了提示——如果用户BMI超过28或者记录到连续一周热量严重超标会弹出提醒“建议前往医院营养科咨询专业人员本系统仅作数据参考”。这个设计既体现责任感也让系统本身更可信。整个项目做完我在Spring Boot和Vue3的应用层面积累了不少实战经验尤其是MyBatis-Plus的自动建表、JWT鉴权链路、ECharts按需加载这些细节几乎每个点都有坑可以讲。如果后续要升级可以接入大模型做个性化食谱推荐——把用户健康档案、近期摄入记录、本地食材库存作为上下文让模型生成更贴近真实情况的膳食方案。业务侧再往前延伸还能对接智能体秤、运动手环的API把体重和运动数据自动同步进来让健康管理闭环真正完整。