企业官网建设流程全解析

做健康类 Web 项目最怕的就是“页面看着简单，真要把营养逻辑和数据模型串起来，处处是坑”。我最近完整跑通了一个基于 Spring Boot + Vue 的健康菜谱生成系统，从需求梳理、源码编写到服务器部署，踩了不少雷，也整理出一套能直接照着做的方案。这个系统的定位很明确：用户先填写一份健康档案，包括身高体重、年龄、饮食目标、忌口和过敏原，系统根据这些参数自动生成一日三餐甚至一周的菜谱，并把热量、蛋白质、脂肪、碳水化合物算清楚。跟那些“随机给你几个菜名”的玩具项目不同，这套系统真正把“营养约束”落地到了推荐逻辑里，对想入门前后端分离开发、或者正在做课程设计和毕业设计的开发者来说，是很好的完整样本。下面我从需求拆解、数据库设计、后端核心逻辑、前端页面实现、部署上线到排错经验，把这套东西完整讲透。

1. 项目概述与需求拆解

1.1 健康菜谱系统到底解决什么问题

很多人想吃得健康，但“吃什么”是个高频难题。打开食谱网站收藏了上百道菜，真到了饭点还是不知道该怎么搭配；健身的人想控制热量，但外卖平台的菜谱压根不标注营养数据；糖尿病患者、过敏人群想吃得安心，又缺乏一套根据个人情况过滤食材的工具。这个健康菜谱生成系统，本质上是把营养师做膳食搭配的逻辑，用代码固化下来。

用户进来之后，不是直接看菜谱，而是先建立一份个人健康档案。系统拿到年龄、性别、身高、体重、活动水平、饮食目标这些信息后，先算出每日推荐摄入热量，再按目标类型拆成蛋白质、脂肪、碳水化合物的比例，最后结合忌口和过敏原过滤食材库，从符合条件的主食、蛋白质来源、蔬菜、水果里组合出菜谱。整个过程用户只要填一次表单，后面每次点“生成今日菜谱”，系统自动完成计算。

这个项目适合三类人：一是想把 Spring Boot 后端和 Vue 前端完整串起来的初学者，可以从中理解接口设计、数据建模和前后端联调；二是在做健康管理类课程设计的学生，功能边界清晰，往上扩展很容易；三是想把自己厨艺或营养知识产品化的开发者，这套逻辑稍作改造就能变成私人营养助手。

1.2 功能需求清单

开发前我没有急着写代码，先把需求收敛成一张清单。这样后面无论是建表还是拆接口，都有据可依，也不会做着做着变成“菜谱展示系统”。

• 用户模块：注册、登录、用户信息维护，登录态用 Token 方式，不依赖 Session。
• 健康档案模块：记录年龄、性别、身高、体重、活动等级、饮食目标（减脂、增肌、保持健康、控糖）、忌口标签、过敏原标签。
• 食材库模块：维护基础食材的营养数据（每 100 克热量、蛋白质、脂肪、碳水），以及食材的分类和标签。
• 菜谱模板模块：预置一批由标准食材组合构成的菜谱，方便快速匹配，也支持系统动态组合食材生成新菜谱。
• 菜谱生成模块：根据健康档案计算热量和营养目标，结合过滤规则生成单日或单餐菜谱，并返回营养分析。
• 收藏与历史模块：用户可以把喜欢的菜谱加入收藏，系统记录生成历史，方便后续个性化优化。

1.3 技术选型背后的考量

技术栈定的是 Spring Boot 2.7 + Vue 3 + Element Plus + MySQL 5.7/8.0。这个组合在中小型项目中非常主流，网上资料多，遇到问题好排查。后端用 Spring Boot 是因为它内置 Tomcat，打成 jar 包就能跑，部署成本低，Spring MVC 的注解开发效率高。持久层用了 MyBatis-Plus，虽然项目也可以用 JPA，但我更倾向于 MyBatis-Plus 的直观 SQL 控制能力和分页插件。

前端选 Vue 3 + Vite 而不是 Vue 2，是因为 Vite 的开发启动速度快，Composition API 写业务逻辑更清晰，Element Plus 的表单和卡片组件很符合后台管理加工具型页面的场景。如果不熟悉 Vue 3，换成 Vue 2 + Element UI 也完全可行，后端接口不用动，只是前端代码组织方式略有差异。

认证方案我没引入 Spring Security，而是用 JWT + 拦截器实现。原因很现实：项目没有复杂的权限树和角色体系，Spring Security 的配置成本偏高，JWT 轻量、无状态，压榨前后端分离场景的匹配度更高。安全细节上做好密码 BCrypt 加密、Token 过期校验就够了。

2. 系统架构与数据库设计

2.1 前后端分离的架构思路

架构采用的是标准的前后端分离。后端只提供 RESTful API，服务端口 8080；前端是纯静态资源，开发环境跑在 Vite 的 5173 端口，生产环境构建后由 Nginx 托管。前后端通过 JSON 进行数据交互，所有需要登录的接口统一在请求头携带Authorization: Bearer <token>。

目录上后端按模块分包，我习惯分为controller、service、mapper、entity、dto、vo、config、common这几层。DTO 用于接收前端提交的数据，VO 用于返回给前端组装好的数据，避免把数据库实体直接暴露给前端。前端则是views放页面组件，api放接口调用，store放全局状态，router放路由，utils放请求封装。

这个架构最大的好处是前后端可以并行开发。后端把接口文档定义好，前端用 Mock 数据先行调页面；后端接口写完后，前端只需要把baseURL指向真实地址，把 Mock 开关关掉，就能平滑对接，不需要等整套系统全部完成再联调。

2.2 数据表结构设计

数据库设计是这类系统最容易出问题的地方，前期字段少了，后面改表结构很痛苦；字段冗余太多，又容易造成数据不一致。我最终保留了六张核心表。

用户表user：主键、用户名、密码密文、昵称、注册时间。健康档案表health_profile：主键、用户 ID、年龄、性别、身高、体重、活动等级、饮食目标、忌口 JSON、过敏原 JSON。食材表ingredient：主键、名称、分类、每 100 克热量、蛋白质、脂肪、碳水、标签 JSON。菜谱模板表recipe_template：主键、名称、分类、烹饪方式、描述、制作步骤、总热量、总蛋白、总脂肪、总碳水。菜谱食材关联表recipe_ingredient：菜谱 ID、食材 ID、用量克数。生成记录与收藏表user_recipe_log：主键、用户 ID、菜谱名称、菜谱内容快照、营养成分快照、生成时间、是否收藏。

2.3 关键表的字段说明

健康档案表是生成逻辑的数据源头，字段设计直接影响后面计算代码的复杂度。活动等级我用枚举数字表示，1 表示久坐，2 表示轻度活动，3 表示中度活动，4 表示高强度活动，计算每日总消耗时直接套系数，不需要再做字符串映射。

忌口和过敏原这两个字段很多人会做成关联表，但考虑到一个用户一般也就存几个标签，用 JSON 数组存储反而更灵活，查询时从 JSON 里取数组，跟食材的标签集合做交集判断即可，不必为这种轻量关系额外建表。

菜谱模板表我额外冗余了总热量、总蛋白这些聚合字段。原因是在用户生成菜谱时，第一轮过滤就要拿模板的总热量和目标热量做比较，如果每次都去关联表现算，性能会随着数据量上升明显恶化。这个冗余字段在写入模板时计算好，查询时直接比对，速度差异非常大。食材关联表里的用量字段以克为单位，营养计算统一按“每 100 克含量 × 用量 / 100”换算，避免出现单位混乱。

3. 后端核心代码讲解：菜谱生成与营养计算

3.1 每日热量需求怎么算

菜谱生成的第一步是算每日推荐总热量，这一步没做好，后面再怎么搭配都是空谈。我采用的是 Harris-Benedict 公式算基础代谢率（BMR），再乘活动系数得到每日总消耗（TDEE）。

男性 BMR 的公式是：88.36 + 13.4 × 体重（公斤） + 4.8 × 身高（厘米） - 5.7 × 年龄。女性则是：447.6 + 9.2 × 体重（公斤） + 3.1 × 身高（厘米） - 4.3 × 年龄。得到基础代谢后，久坐人群乘 1.2，轻度活动乘 1.375，中度活动乘 1.55，高强度活动乘 1.725。

计算完 TDEE 之后，再根据饮食目标做热量调整。减脂目标在 TDEE 基础上减去 300 到 500 千卡，增肌目标加上 200 到 300 千卡，保持健康和控糖目标则直接使用 TDEE。控糖用户我还会额外限制单次摄入的简单碳水来源。这一段代码在HealthCalculator工具类里实现，抽成纯静态方法，方便单元测试。

public class HealthCalculator { public static double calcBmr(boolean male, double weightKg, double heightCm, int age) { if (male) { return 88.36 + 13.4 * weightKg + 4.8 * heightCm - 5.7 * age; } return 447.6 + 9.2 * weightKg + 3.1 * heightCm - 4.3 * age; } public static double calcTdee(double bmr, int activityLevel) { double[] factors = {1.2, 1.375, 1.55, 1.725}; return bmr * factors[activityLevel - 1]; } public static double calcTargetCalories(double tdee, String goal) { switch (goal) { case "LOSE": return tdee - 350; case "GAIN": return tdee + 250; default: return tdee; } } }

这里有个容易踩坑的点：体重的录入单位必须统一。前端表单要明确标注公斤和厘米，后端接口也要加参数校验，否则用户填了斤和米，算出来的结果会差出一个数量级。我在 DTO 里用@DecimalMin和@Max注解做了范围限制，超出直接返回参数错误。

3.2 菜谱推荐算法的实现

推荐算法没有用复杂的机器学习模型，而是采用“规则过滤 + 贪心组合”的方案。核心思路是先把食材按分类划分成主食、蛋白质、蔬菜、水果、奶类五组，然后根据用户忌口和过敏原过滤掉不合格的食材，再按照营养目标逐步选定每组的候选食材。

第一步，从用户健康档案中取出忌口和过敏原标签，与食材表里的标签字段做交集。食材的标签设计成 JSON 数组，例如["辛辣", "含坚果"]，如果用户忌口里有“含坚果”，这个食材就直接排除。第二步，根据目标热量反推每组食材的热量份额。我的经验是：减脂目标下，碳水供能占比 40%，蛋白质 30%，脂肪 30%；增肌目标下，碳水 45%，蛋白质 35%，脂肪 20%；控糖和保持健康则采用比较均衡的 50%、25%、25%。

确定比例后，把每日总热量切成三顿：早餐 30%、午餐 40%、晚餐 30%。每顿再按比例算出主食、蛋白质、蔬菜应该提供的热量区间。最后从过滤后的食材库里，按分类随机选取候选食材，用贪心组合不断计算组合后的营养总和，直到落入目标热量区间或者达到最大尝试次数。如果失败，就降级到菜谱模板表中匹配最接近的热量模板返回给用户。

public List<RecipeResult> generateDailyRecipes(HealthProfile profile, String goal) { double target = HealthCalculator.calcTargetCalories( HealthCalculator.calcTdee( HealthCalculator.calcBmr(profile.isMale(), profile.getWeightKg(), profile.getHeightCm(), profile.getAge()), profile.getActivityLevel()), goal); List<Ingredient> candidates = ingredientMapper.selectAvailable( profile.getAllergyTags(), profile.getAvoidTags()); Map<String, List<Ingredient>> grouped = groupByCategory(candidates); List<RecipeResult> recipes = new ArrayList<>(); for (MealRatio ratio : MealRatio.values()) { double mealCalories = target * ratio.percent; RecipeResult recipe = greedyCombine(grouped, mealCalories, goal); recipes.add(recipe); } return recipes; }

贪心组合的逻辑是：每次从当前分类里选一种未使用的食材加入组合，计算累计热量是否超限；如果未超限则继续加下一类，如果超限就换一种热量更低的同类食材。这个方案的好处是可控性极强，营养数据实时可算，坏处是有时组合出来的搭配比较常规，缺少惊喜感，但对健康菜谱场景来说，稳定和可控远比“出乎意料”重要。

3.3 接口设计与返回结构

接口设计遵循一个原则：后端返回的数据是前端“可以直接用的”而不是“还要二次处理的”。菜谱生成接口/api/recipe/generate返回的是组装好的DailyPlanVO，里面包含三餐，每餐包含菜谱名称、食材明细、用量、营养汇总和制作步骤。

接口鉴权统一走拦截器。拦截器里解析请求头中的 Token，把用户 ID 放到ThreadLocal上下文，后续 Service 层直接从上下文取当前用户，避免在接口参数里频繁传用户 ID。这样设计的好处是代码干净，安全性也集中在一个点维护。

@RestController @RequestMapping("/api/recipe") public class RecipeController { @PostMapping("/generate") public Result<DailyPlanVO> generate(@RequestBody GenerateRequest request) { Long userId = UserContext.getUserId(); DailyPlanVO plan = recipeService.generatePlan(userId, request.getDateType()); return Result.ok(plan); } }

返回结构统一封装成Result<T>，包含code、message、data三段。前端 Axios 响应拦截器统一判断code，为 200 就直接取data，非 200 就弹出错误提示。这样做减少了大量重复的错误处理逻辑，接口联调时也容易追踪问题。

4. 前端核心代码讲解：Vue 页面与交互

4.1 前端项目结构与状态管理

前端我用 Vue 3 + Vite 搭建，src下按views、components、api、store、router、utils划分。路由采用前端守卫，没有 Token 时访问需要登录的页面会被重定向到登录页。状态管理用了 Pinia，主要存用户信息和健康档案的快照，这样用户从档案页填完信息跳到菜谱页，不需要重新请求接口。

Axios 实例在utils/request.js里统一创建，baseURL根据环境变量区分开发和生产。请求拦截器里把 Token 加到请求头，响应拦截器里处理 Token 过期跳转登录页的问题。这个封装是所有页面交互的基础，一定要在最开始就写好。

import axios from 'axios' import { ElMessage } from 'element-plus' const request = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL || '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( res => { const { code, message, data } = res.data if (code === 200) { return data } ElMessage.error(message || '请求失败') return Promise.reject(new Error(message)) }, err => { if (err.response && err.response.status === 401) { localStorage.removeItem('token') window.location.href = '/login' } ElMessage.error('网络异常') return Promise.reject(err) } ) export default request

4.2 健康档案表单的实现

健康档案页是系统最重要的入口，用户填的数据直接决定菜谱生成质量。我把表单分成个人信息、身体数据和饮食偏好三个区块，用 Element Plus 的el-form做校验。性别用单选按钮，活动等级用带说明的选择器，忌口和过敏原用多选标签组，选项数据来自后端统一字典接口。

提交时整个表单作为一个对象传给/api/health/profile。这里有个小设计：接口设计成“有则更新、无则新增”，通过用户 ID 判断当前档案是否存在。前端在onMounted时会拉取一次已有档案回填表单，用户修改后再次提交，避免出现多份互相矛盾的档案数据。提交成功后 Pinia 里同步更新健康档案快照，提示用户“档案已保存”，再跳转到菜谱生成页面。

表单校验的细节很容易被忽略，但恰恰是这类工具型项目交互体验的关键。体重字段必须输入数字，还要限制有效范围，比如 20 到 300 公斤；年龄限制在 10 到 100 之间；身高限制在 100 到 250 厘米。Element Plus 的规则里配置type: 'number'和min、max，提交时如果校验不通过，表单会直接红字提示，不让无效数据进入后端。

4.3 菜谱展示与交互

菜谱生成页是系统最核心的展示页。页面顶部是一个“生成今日菜谱”的大按钮和一个日期选择器，用户选择某天后点击生成，前端调用/api/recipe/generate接口，拿到包含三餐的DailyPlanVO数据。

为了让展示更直观，我用el-card分三列展示早、中、晚餐，每张卡片顶部是菜谱名称，中间是食材列表和用量，底部是营养数据条。营养数据我用 Element Plus 的el-progress展示热量占目标热量的百分比，颜色根据是否超标切换，超标时变成警告色。这个细节用户反馈非常好，一眼就能看出今天的热量预算是否用完。

收藏功能的实现也值得一提。每张菜谱卡片右上角有个收藏图标，点击后调用/api/recipe/collect接口，把菜谱 ID 传给后端。后端把菜谱内容连同营养快照一并存储，这样即使用户后续修改了自己的健康档案，收藏记录里的菜谱依然保留着当初生成时的完整数据，不会出现“档案一变，收藏的菜谱内容跟着变”的诡异情况。

4.4 接口联调与请求封装

前后端联调阶段，我一般会先和后端同事核对接口文档，确认每个接口的请求方法、路径、参数名和返回结构。最好在开发前就约定好统一返回格式，避免前端写res.data.data.list，后端返回的却是res.result.items，这种字段不一致联调起来非常痛苦。

在实际联调中我习惯用 Vite 的代理功能解决开发环境跨域问题。在vite.config.js里配置代理，把/api前缀的请求转发到http://localhost:8080，前端代码里不需要写完整的后端地址，生产环境也更容易切换。这个配置不需要后端做任何 CORS 改动，开发体验比后端配合跨域要顺畅得多。

export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

5. 部署文档与上线流程

5.1 本地环境准备

部署前先把本地环境准备好。需要安装 JDK 8 或 11、Maven 3.6+、Node.js 16+、MySQL 5.7 以上版本。第一次运行项目时，先在 MySQL 里执行初始化脚本创建数据库，数据库名用healthy_recipe，字符集设为utf8mb4，排序规则用utf8mb4_general_ci。

后端配置文件application.yml里需要重点确认数据库地址、账号密码和 JWT 密钥。JWT 密钥不要用默认值，建议替换成一段足够长的随机字符串，否则生成的 Token 存在被伪造的安全风险。Redis 如果项目用到了缓存，也要在配置里确认连接信息。

前端第一次启动前执行npm install安装依赖。如果网络较慢，可以把 npm 源切换成国内镜像源，安装速度会快很多。安装完成后执行npm run dev，本地开发服务会跑在 5173 端口。这时前后端通过 Vite 代理完成联调，所有接口都走/api前缀转发到后端。

5.2 后端打包与启动

后端打包前先执行mvn clean package -DskipTests跳过测试。打包完成后target目录下会生成一个可执行的 jar 包，名称类似healthy-recipe-0.0.1-SNAPSHOT.jar。启动命令很简单，但有几个参数要特别注意。

标准启动命令是java -jar healthy-recipe-0.0.1-SNAPSHOT.jar。如果服务器内存有限，可以加上-Xms256m -Xmx512m限制 JVM 最大堆内存，防止应用内存占用过高影响同机其他服务。生产环境我习惯用nohup后台运行，并把日志输出到指定文件，这样即使终端关闭，服务也能继续运行，方便事后排查日志。

nohup java -Xms256m -Xmx512m -jar healthy-recipe-0.0.1-SNAPSHOT.jar \ --spring.profiles.active=prod \ > app.log 2>&1 &

第一次启动时一定要先确认数据库连接和初始化脚本已经执行成功，否则服务启动过程中会因为找不到数据表直接报错。启动完成后通过curl http://localhost:8080/api/health访问健康检查接口，返回正常 JSON 说明后端已经就绪。如果服务启动却访问失败，优先查看日志中的端口占用和数据库连接异常。

5.3 前端构建与 Nginx 发布

前端发布前执行npm run build，Vite 会生成dist目录，里面是纯静态文件。把这些文件上传到服务器后，还需要配合 Nginx 完成静态资源托管和接口反向代理。

生产环境我一般不直接把后端地址写死在前端代码里，而是通过 Nginx 把/api路径反向代理到后端的 8080 端口。这样前端代码保持“请求同源路径”，Nginx 在中间做转发，浏览器不会产生跨域问题，部署也更灵活。就算后端换端口或迁移到别的机器，只需要改 Nginx 配置，前端不用重新构建。

server { listen 80; server_name your-domain.com; root /var/www/healthy-recipe/dist; index 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; } location / { try_files $uri $uri/ /index.html; } }

这里最关键的是try_files $uri $uri/ /index.html;这段配置。前端是 Vue 的 SPA 应用，路由走的是 History 模式，如果不加这个配置，用户在菜谱详情页直接刷新浏览器，Nginx 会找不到对应的实际文件路径，返回 404。把不存在请求重写到index.html后，Vue Router 会重新接管路由，页面正常渲染。

6. 常见问题与排查技巧实录

6.1 跨域请求被拦截

开发环境跨域其实通过 Vite 代理已经解决了，但生产环境仍然会遇到跨域问题，多数是 Nginx 配置没生效，或者代理路径写错了。排查时可以打开浏览器开发者工具，看请求的响应头里是否带有Access-Control-Allow-Origin，如果没有，说明请求根本没有到达后端，问题出在代理层。

还有一种情况是后端单独启动了多个实例，或者把 Swagger 等调试接口暴露在生产环境。Swagger 本身没问题，但正式上线时要注意关闭或加上访问限制，否则接口结构会被外界看到，存在信息泄露风险。

6.2 数据库连接与中文编码问题

数据库层面经常遇到两类问题。第一类是启动时报“Public Key Retrieval is not allowed”，这通常是 MySQL 8.0 的驱动行为变更导致的，需要在 JDBC 连接串上加allowPublicKeyRetrieval=true参数。第二类是中文乱码，虽然建库时指定了utf8mb4，但连接串里没有加characterEncoding=utf8时，某些版本驱动仍然会用默认编码，导致菜名和食材名称乱码。

检查数据库编码时，用SHOW CREATE TABLE查看表的默认字符集，再用SHOW VARIABLES LIKE 'character%'确认服务端连接层配置。我建议在application.yml的 JDBC 连接串里直接加上三件套：useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai。时区配置也很重要，不设置时区可能在插入时间和读取时间时偏差 8 小时。

6.3 菜谱生成结果异常怎么排查

用户反馈“生成的菜谱热量明显偏高”或“没有菜谱可生成”时，我有一套固定的排查路径。先看健康档案里用户录入的数据是否合理，体重是否按公斤填写；再看用户选的饮食目标是否被正确传到了后端；最后查看生成的日志里，推荐的模板 ID 和目标热量是否符合预期。

如果日志显示目标热量正常，但候选食材为空，多半是食材标签和用户忌口标签对不上，导致全部被过滤。这里要重点检查标签的匹配逻辑是否是全等比较，比如用户选了“坚果”，而食材标签存的是“含坚果”，两个字符串完全不同，过滤时永远匹配不上。我的解法是统一标签字符串前缀，比如都用“坚果过敏”这种统一词条，避免同义不同词的问题。

还有一次线上问题表现为“每次生成的菜谱都一样”。排查后发现随机种子的问题，贪心组合在候选食材较少时，随机选择的路径几乎相同，每次都选择了列表里靠前的食材。解决方法是先把候选食材顺序打乱，再执行贪心组合，保证结果有足够随机性，同一用户多刷几次不会总是同一份菜谱。

6.4 部署上线后的优化经验

系统上线后，用户一多就会暴露性能问题。最直观的表现是菜谱生成接口响应变慢，排查后发现每次生成都要查一遍食材表和模板表。优化方向有两个：一是给常用查询条件建联合索引，比如食材表按分类和标签字段建索引；二是把食材库这类低频变动的数据放进 Redis 缓存，生成菜谱时优先从缓存读取候选食材，缓存失效再回源数据库。

缓存更新策略要特别注意一致性。管理员在后台新增食材或修改营养数据后，必须同步清理相关缓存，否则用户生成菜谱时读到的还是老数据。我在后台的食材保存接口里加了一步删除 Redis 中对应分类键的操作，牺牲了一点实时性，换来了实现简单和逻辑清晰。个人体检下来，生成接口的响应时间从原来的 300 毫秒左右下降到 60 毫秒以内，对这类系统来说完全够用。

7. 源码阅读与二次开发建议

7.1 源码阅读顺序

拿到整套源码后，不建议从pom.xml开始逐行精读，那样效率太低。我建议按业务链路顺序看：先看数据库初始化脚本，了解有哪些表和字段；再看实体类和 Mapper，知道数据如何流转；接着看 Service 里菜谱生成的核心方法，这是整个系统的灵魂；最后看 Controller 确认接口路径和入参出参。

前端部分先看utils/request.js，理解请求封装逻辑；再看router，了解页面路由与登录守卫；然后看健康档案页和菜谱生成页，这是两个最核心的页面。看完这些再看收藏、历史记录等辅助模块，整体框架就清晰了。我整理源码注释时，重点在核心算法的关键步骤上加了详尽注释，包括热量公式来源和贪心组合的意图，阅读体验比看干巴巴的代码好很多。

7.2 功能扩展方向

系统做完了，后续扩展空间很大。比较实用的是加入食材替换功能，用户对某道菜中的某样食材过敏时，系统自动推荐营养成分类似的替代食材，这个功能在源码的食材分类和营养字段基础上做，工作量不大但价值很高。也可以在现有生成逻辑上加入“口味偏好”，比如用户喜欢清淡，就在筛选条件里过滤掉高油高盐的烹饪方式。

另一个方向是把健康档案的维度加厚，加入体检数据导入、运动记录同步等功能。后端接口预留了扩展位，前端页面也可以逐步增加图表展示。只要保持现有的分层结构，这些功能基本都是加分项，不会颠覆核心架构。

我自己的体会是，像这种“规则清晰、边界明确”的项目，只要数据模型设计扎实，后续功能扩展会非常顺手。最怕的是前期图方便把所有字段堆在一张表里，后面想加维度时才发现无从下手。这套健康菜谱生成系统做完之后，最大的收获不是某个算法有多高明，而是把一个模糊的“吃得健康”概念，拆解成了可计算的热量、可过滤的标签、可组合的食材三件事。按这个思路去做任何规则型推荐系统，都能少走很多弯路。