企业官网建设流程全解析

打开微信开发者工具的那一刻，大多数毕设选手的内心其实是懵的。页面怎么写、接口怎么调、食物数据从哪来、营养分析怎么算，这些在开题报告里看起来都清清楚楚的问题，真到了动手阶段，每一环都能卡住你三五天。这篇内容就是给正在做或准备做“基于微信小程序的膳食健康管理系统”这个题目的同学写的，我会把整个系统从需求拆解到功能落地再到上线踩坑，一条线讲透，代码和思路都可直接复用。

先说结论：这个题目在计算机毕设里属于“中等偏上难度、高分回报率”的类型。它既有微信小程序前端，又有后端服务，还涉及营养学领域的基础计算逻辑，展示的时候可以讲的故事很多——从食物识别、热量计算到个人健康档案，每一块都能展开。但它最大的坑也恰恰在这里：一旦你只把它当成一个“增删改查”项目来做，答辩的时候就会非常单薄。

所以，这篇内容我打算先带你拆掉题目本身——把“膳食健康管理系统”这个抽象名字，翻译成具体的功能清单和数据库表结构；再给你一套能直接落地的技术方案；然后进入核心代码和实操细节；最后把我在测试和上线过程中遇到的坑，一条一条列出来。整个过程不绕弯子,你照着做,至少能节省两周以上的无效摸索时间。

1. 系统整体设计与思路拆解

1.1 这个系统到底要解决什么问题

“膳食健康管理”听起来是一个很大很泛的概念，但落到一个毕设项目里，它必须收窄成一个具体的、可验证的功能闭环。我建议这样理解：用户打开小程序，记录自己每天吃了什么，系统根据食物数据算出热量和营养素摄入，再结合用户的个人身体参数（身高、体重、年龄、活动量），给出一个饮食评价和调整建议。

核心业务闭环是“记录 → 计算 → 评估 → 建议”，四个环节缺一不可。

只做记录不做分析，就是一个备忘录，没有技术含量；只做分析不做记录，就是无源之水，数据都是编的。只有把这条链路完整打通，系统的价值感才能体现出来，也才能在答辩的时候说清楚你的系统到底做了什么。

1.2 用户角色与核心功能划分

系统不建议做太复杂的角色体系，两条线就够了：普通用户端和管理员端。

普通用户端是整个系统的核心，功能按使用频率排序如下：

• 用户注册登录：微信授权登录为主，手机号绑定作为辅助，不要自己单独做一套账号密码体系，又慢又不讨好
• 个人健康档案：填写性别、出生年份、身高、体重、活动强度，用于计算每日推荐摄入热量（BMR基础代谢率 + TDEE总能量消耗）
• 膳食记录：这是最高频的功能，用户选择一餐（早餐/午餐/晚餐/加餐），搜索食物并填写份量，记录当日摄入
• 食物数据库检索：支持关键词搜索、分类浏览，每个食物需要包含热量、蛋白质、脂肪、碳水化合物、膳食纤维等核心营养数据
• 营养分析：按日/周/月维度展示热量摄入趋势，对比推荐摄入量，分析三大营养素供能比例
• 健康建议：根据分析结果生成简单可读的提示内容，例如“本周蛋白质摄入偏低，建议增加蛋奶类摄入”
• 个人中心：修改档案、查看历史记录、数据导出或清空

管理员端做轻量版，不需要做成完整后台管理系统那种体量：

• 食物库管理：新增食物、编辑营养数据、上下架
• 用户管理：查看用户列表、禁用异常账号
• 数据统计首页：用户总数、日活跃记录数、热门食物排行

很多同学会在管理员端功能上控制不住，越加越多，最后变成一场漫长的自我消耗。毕设项目讲究的是功能闭环完整、逻辑自洽，而不是功能数量堆砌。你能把上述这些做扎实，已经足够应付答辩和演示了。

1.3 为什么这个选题容易拿高分

这个题目有一个天然优势：它同时踩中了“技术”和“业务”两个评分维度。

技术维度上，前端是微信小程序，涉及组件化开发、本地缓存、网络请求封装、图表组件适配；后端是接口服务，涉及用户认证、数据校验、复杂的聚合统计查询。这些都是面试官和评委会重点关注的能力点。业务维度上，系统涉及健康数据计算、目标管理、可视化分析，这些能体现你的需求分析能力和产品设计能力，而不是一个单纯的“增删改查搬运工”。

我见过很多分数不低的同类项目，它们的共同特点是：在基础功能之外都有一到两个“亮点工程”。比如食物搜索联想、月度热力图展示、饮食评分卡，甚至对接了免费的食物OCR识别接口。哪怕只把这些做出一两个，答辩现场的效果就会立刻不一样。后面我会给出具体建议，哪些亮点性价比最高。

2. 技术方案选型与核心细节解析

2.1 前端：原生小程序还是uniapp

这是你会遇到的第一个选择题。原生小程序使用微信官方语法（WXML、WXSS、JS），uniapp则是一套支持多端发布的Vue语法框架。我的建议很明确：如果这个项目只作为毕设，不打算发布到支付宝、抖音、鸿蒙等多端，用原生就足够了，学习曲线更短，调试更方便，遇到问题时社区答案直接可参考。原生开发的代码结构也更贴合小程序自身的生命周期，写起来直白。

如果你计划以后从事跨端开发工作，或者想同时出App版本演示，那选uniapp也确实是一个合理选项。需要注意一点：uniapp写完之后仍然需要在小程序开发者工具里编译运行，并没有省掉微信开发者工具这一环。对于毕设节奏来说，它反而多了一层编译概念需要理解。

无论选哪个，我建议在小程序端做这些技术约定：

• 请求封装独立成utils层，统一处理baseURL、token注入、错误提示、超时控制
• 页面数据统一通过接口获取，不在前端写死测试数据，方便答辩演示时切换真实环境
• 使用微信账号登录，获取openid后与后端用户表绑定，下次进入自动静默登录

2.2 后端：SpringBoot是毕设场景的安全牌

后端选型上，SpringBoot是当前计算机类毕设最稳妥的选择，没有之一。它的生态成熟、资料丰富、答辩时老师的接受度高。结合MyBatis-Plus做数据访问，省去大量手写SQL的重复工作，再把重点放在业务逻辑本身的实现上。

如果你的Java基础比较薄弱，那么SpringBoot + MyBatis-Plus + MySQL这套组合最大的好处是“约定大于配置”，几乎所有毕设需要的功能都有现成模板可以参考。这里需要特别留意的版本兼容问题，我后面在踩坑部分细说。

项目结构建议按标准分层模式搭建：

com.example.diet ├── controller // 接收请求、参数校验、返回结果 ├── service // 业务逻辑层，核心计算都在这里 ├── mapper // 数据访问层 ├── entity // 数据库实体类 ├── dto // 前端交互参数对象 ├── common // 通用返回结果、异常处理、工具类 └── config // 配置类（拦截器、跨域、WebMVC）

2.3 数据库设计：五张核心表撑起整个系统

数据库是毕设系统最重要的一层，也是最容易被低估的一层。很多同学一开始就急着写代码，后面发现表结构不合理，返工成本极高。我把这个系统的核心表结构整理了一下，照着落地基本够用。

用户表user_info：

食物表food_info：

膳食记录表diet_record：

健康档案表health_profile：该表与用户表为一对一关系，主要存的是BMI、基础代谢率BMR、每日推荐摄入热量target_calorie等计算结果，这样在展示分析页时不需要每次实时计算，查询效率更高。

建议表diet_advice：存管理员预设的建议模板，按条件匹配，例如“蛋白质偏低”“热量超标”“膳食纤维不足”各对应若干条建议文案。

2.4 核心算法逻辑：热量和营养素计算怎么做

整个系统里最有技术含量的部分是营养计算逻辑，它不复杂，但要算得对、算得合理。

要算“每日推荐摄入热量”，需要先用Mifflin-St Jeor公式计算基础代谢率BMR：

男性：BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 + 5 女性：BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 - 161

然后根据活动系数得到TDEE：

• 久坐少动（1.2）
• 轻度活动（1.375）
• 中度活动（1.55）
• 高强度（1.725）

每日推荐摄入热量 = BMR × 活动系数。

记录某餐摄入时，按食物份量比例换算：摄入热量 = 食物100g热量 × 实际克数 / 100，三大营养素同理。最后按日聚合所有记录，得到当日总摄入。三大营养素供能比的计算方法是：蛋白质供能 = 蛋白质克数 × 4千卡，脂肪供能 = 脂肪克数 × 9千卡，碳水供能 = 碳水克数 × 4千卡，分别除以总热量即可得到百分比。合理范围参考：碳水化合物50%-60%，蛋白质10%-20%，脂肪20%-30%。这个逻辑不必追求医学级精度，但必须自洽，并且要在答辩时能清晰解释。

3. 实操过程与核心环节实现

3.1 后端工程初始化与基础配置

先用Spring Initializr或IDEA自带工具创建SpringBoot项目，Java版本建议用JDK 8或11，不要一上来就追新。JDK 17以上版本虽然也能跑，但在毕设场景里没必要冒险，一组兼容问题可能就消耗你一整晚。

pom.xml里需要引入的关键依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency> <dependency> <groupId>com.auth0</groupId> <artifactId>java-jwt</artifactId> <version>3.19.2</version> </dependency>

application.yml里的关键配置：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/diet_health?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

这里需要特别提醒的是时区问题。如果你的数据库连接串里没有serverTimezone=Asia/Shanghai，部署到服务器后时间会差8小时，排查起来非常隐蔽。还有map-underscore-to-camel-case开启后，数据库字段record_date才能自动映射到实体的recordDate，不配置就会因为字段名不匹配查询不到数据。

3.2 微信登录与用户体系实现

小程序端调用wx.login获取临时code，发送到后端，后端调用微信接口换取openid。这里有一个很实用的细节：wx.getUserProfile接口在2022年后调整过，现在获取头像昵称需要用户主动点击授权按钮，不能一进页面就弹窗。所以毕设项目建议采用“先静默登录、后完善资料”的模式——进入小程序即用code换openid创建用户，用户进个人中心时再主动填档案。

后端登录接口：

@PostMapping("/login") public Result login(@RequestBody LoginRequest request) { // 使用code换取openid String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid + "&secret=" + secret + "&js_code=" + request.getCode() + "&grant_type=authorization_code"; // 发起HTTP请求获取openid // 查询用户表，不存在则创建新用户 // 生成JWT token并返回 }

token方案可以使用JWT，将userId放入payload中，设置7天过期时间。小程序端拿到token后存到storage，每次请求放在header里，后端用拦截器统一解析校验。这个方案简单、清晰，答辩时能讲清楚，也不用引入Spring Security这种重框架，否则光是security的配置和过滤器理解就能让你多花三四天。

3.3 食物数据库的构建策略

食物数据从哪来，是几乎所有做这个题目的同学都会卡住的地方。一份“看起来像那么回事”的食物库至少需要300条数据，覆盖主食、肉类、蔬菜、水果、蛋奶、豆制品、零食多个类别。数据源可以是公开的食物成分表，网络上可以找到整理好的Excel或JSON版本，也可以用免费的食物营养数据API，调用后存入库中。

我建议采用“预置+管理”双轨制：系统上线前批量导入一份基础食物数据（300-500条），上线后管理员通过后台维护新食物。需要注意的是，数值必须看起来真实，每100g米饭热量116千卡、每100g鸡胸肉热量133千卡这样的基础常识不能错。答辩时评委很可能随手搜一个食物来核对，数据错了会非常减分。

食物表在导入时可以用一段批量插入脚本，SQL文件准备好后一次性执行。数据格式类似：

INSERT INTO food_info (name, category, calories, protein, fat, carbohydrate, fiber, unit_desc) VALUES ('米饭', '主食', 116, 2.6, 0.3, 25.9, 0.3, '1碗约200g'), ('鸡胸肉', '肉类', 133, 19.4, 5.0, 2.5, 0, '1块约150g'), ('苹果', '水果', 52, 0.2, 0.2, 13.7, 1.7, '1个约200g');

3.4 小程序端核心页面实现

小程序端我建议页面结构如下，保持精简但功能完整：

• pages/login（登录页）
• pages/home（首页，展示今天摄入概况）
• pages/record（记录页，选择餐次、搜索食物、填写份量）
• pages/stats（分析页，图表展示）
• pages/profile（个人中心）
• pages/food-detail（食物详情页）

首页和记录页是使用频率最高的页面，也是评委打开后第一眼看到的页面，交互做得好不好直接影响第一印象。首页设计为“今日概况卡片”模式：顶部显示日期和今日已摄入热量，用进度条展示与目标热量的占比，下面放“早餐/午餐/晚餐/加餐”四个入口卡片，点击直接进入对应餐次的记录流程。

记录页的核心是一个搜索框 + 分类筛选器。用户可以输入食物名称关键词，下方列表展示匹配的食物，每一项显示名称、每100g热量、常见份量描述。用户点击后弹出份量选择组件，支持滑动选择或数字输入，实时显示“本次摄入XX千卡”。这个交互细节很关键，它让用户可以即时看到计算结果，是整个系统里用户感知最强的设计。

下面是记录提交的核心前端逻辑示例：

// pages/record/record.js 中的提交方法 submitRecord() { const { food, weight, mealType } = this.data if (!food || !weight) { wx.showToast({ title: '请选择食物和份量', icon: 'none' }) return } const calories = (food.calories * weight / 100).toFixed(0) const protein = (food.protein * weight / 100).toFixed(1) // 组装营养数据后提交到后端 const data = { foodId: food.id, mealType, weight, recordDate: this.data.currentDate, calories, protein, } request.post('/diet/record', data).then(res => { wx.showToast({ title: '记录成功', icon: 'success' }) // 刷新首页数据 }) }

在本地计算热量值再传给后端，可以显著降低后端聚合统计的压力，同时保证前端反馈的即时性。但要注意体重参数校验，比如米饭实际摄入量填了5000g这种数据要能拦下来，关键词就是合理性检查。我的方案是限制单次记录份量在10g-1000g之间，超出范围直接Toast提示。

3.5 营养分析页的图表实现

分析页是系统的第二个“面儿”，直接用文本罗列数据太干瘪，必须上图表。小程序端图表推荐使用ec-canvas（ECharts小程序版）或uCharts。两者选哪个各有利弊，ec-canvas比较重但图表类型丰富、文档多；uCharts轻量一些但部分图表类型需要授权。

我选了ec-canvas，用折线图展示近7天热量摄入趋势，用饼状图展示当日三大营养素供能比。加载图表组件时有一个常见坑：ECharts初始化需要一定的dom渲染时间，在onReady生命周期里初始化成功率最高，不要在onLoad里急着初始化，否则图表会不显示或者空白。数据加载完成后通过setOption更新图表，注意数据要按日期排序，不是按查询结果顺序排列。

图表数据接口设计：

@GetMapping("/diet/stats") public Result stats(@RequestParam Long userId, @RequestParam String startDate, @RequestParam String endDate) { // 按日期分组聚合查询 // 返回每天总热量、蛋白质、脂肪、碳水化合物 // 同时返回用户的每日推荐摄入热量作为对比基准 }

SQL层面可以这样写：

SELECT record_date, SUM(calories) AS total_calorie, SUM(protein) AS total_protein, SUM(fat) AS total_fat, SUM(carbohydrate) AS total_carb FROM diet_record WHERE user_id = #{userId} AND record_date BETWEEN #{startDate} AND #{endDate} GROUP BY record_date ORDER BY record_date

查询结果按日期分组返回后，前端再补齐缺失日期的数据。比如近7天里用户只记录了3天，那么剩下4天的热量值应该补0，否则折线图会断掉，看起来像系统出bug了。

3.6 健康建议模块的设计

健康建议模块是内容生成式的，不建议做复杂算法，用“规则匹配 + 模板文案”就能做出不错的效果。系统根据用户的营养分析结果，逐条判断并拼接建议内容：

• 如果蛋白质供能比低于10%，匹配“蛋白质摄入偏低，建议每餐增加一个鸡蛋或一杯牛奶”
• 如果脂肪供能比高于30%，匹配“脂肪摄入偏高，建议减少油炸食品和肥肉摄入”
• 如果当日总热量超出目标值的120%，匹配“今日热量摄入超标，建议晚餐选择清淡蔬菜”
• 如果膳食纤维摄入低于25g，匹配“膳食纤维不足，建议增加全谷物和绿叶蔬菜”
• 如果连续3天记录完整，匹配“记录习惯良好，继续保持”

在数据库里建一张advice_template表，字段包括condition_type（条件类型）、threshold_min、threshold_max、content。后端分析时循环匹配，返回建议列表。这个模块看着不大，但在答辩时非常讨巧，因为它直接体现了你从数据分析到业务应用的完整思路。

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

4.1 微信开发者工具里的高频报错

我把自己在开发过程中遇到频率最高的问题做成一个速查表，供你对照排查，很多问题不需要上网搜就能解决。

4.2 部署与上线过程中的几个坑

部署是本项目中最容易翻车的一环。你代码全写完了，但是在微信公众平台“开发管理→开发设置→服务器域名”里没有配置合法域名，真机预览时接口直接全部请求失败。这个配置需要你的后端接口必须走HTTPS协议，也就是说你需要一台云服务器，再给域名做好备案和HTTPS证书。如果你的预算和时间都比较紧张，还有一条路是使用微信云托管或云开发CloudBase，小程序端可以用wx.cloud.callFunction方式请求云函数，省去域名备案的流程。

但我要提醒你一点：如果走云开发路线，你的项目架构会发生较大变化，后端不再是独立的SpringBoot服务，而是云函数。这个选择要在开题时就想清楚，不要代码写了一半再换方案。采用自建服务器方案时，服务器配置不需要很高，1核2G的轻量应用服务器足够支撑毕设演示的并发量。

上线前还有一件事必须做：在小程序后台配置合法请求域名，并且把HTTP改成HTTPS。没有HTTPS，微信会直接拦截所有请求。Nginx配HTTPS证书其实不复杂，申请免费证书后一段配置就能跑起来：

server { listen 443 ssl; server_name yourdomain.com; ssl_certificate /etc/nginx/ssl/yourdomain.pem; ssl_certificate_key /etc/nginx/ssl/yourdomain.key; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

4.3 小程序审核经验

如果你的最终目标是真正上线发布到微信平台，那审核这一关绕不过去。就膳食健康小程序来说，审核被拒最常见的理由是“医疗健康类目资质”问题。微信对涉及医疗、药品、保健功能的类目审核非常严格，你的系统如果出现“治疗”“疗效”“药用”等字眼，大概率被驳回。解决办法是弱化医疗属性、强化生活记录属性：把系统描述为“记录每日饮食、查看营养摄入的辅助工具”，而不是“健康诊断系统”。建议文案要避免绝对化表述，不要写“可治愈”“能改善某某病”，只用“推荐”“建议”“参考”这类词。

你的代码里也不能存在隐藏的“治疗”暗示，食物名称和推荐文案里的每一个词都值得过一遍。不少同学的审核噩梦都出在这上面，改一版文案，重新提审，等两三天，再被驳回，来来回回一周就没了。提前把文案规范化，这个时间就能省下来。

4.4 后端常见的编译与版本问题

SpringBoot版本和MyBatis-Plus版本不兼容是最典型的编译报错来源。有些同学从网上找个模板，SpringBoot用的是2.7，MyBatis-Plus用的是最新版（对应SpringBoot3），启动时直接报Failed to configure a DataSource或者各种类找不到。这里给你一个稳定的版本组合：SpringBoot 2.7.x + MyBatis-Plus 3.5.x + MySQL 5.7或8.0，这个组合经过了大量项目的验证，问题最少。

还有一类问题是Lombok版本与JDK版本不兼容导致的编译失败。JDK11以上时，Lombok版本过旧会报java: java.lang.ExceptionInInitializerError。解决方法是在pom中指定较新版本：

<dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.30</version> <optional>true</optional> </dependency>

另一个隐蔽问题是跨域。小程序请求后端时不存在浏览器同源策略限制，所以不需要处理CORS，但如果你用浏览器直接访问后端接口做测试，就可能遇到跨域错误。为了联调方便，建议还是加一个CORS配置类，允许所有来源访问，开发期会舒服很多。

5. 拿出来就能用的几个亮点建议

5.1 亮点一：食物搜索联想

在小程序搜索框里输入关键词时，通过防抖请求后端接口获取匹配的食物列表，下拉显示联想结果。这个功能技术实现非常简单，但用户体验提升极其明显。后端就是一个模糊查询接口：SELECT * FROM food_info WHERE name LIKE CONCAT('%', #{keyword}, '%') LIMIT 10，前端加上300ms的防抖即可。

5.2 亮点二：每日饮食评分卡

记录完一顿饭后，根据当前摄入量与推荐值的接近程度，给出一个60-100的评分，评分附带一句话描述：热量刚好，“搭配不错”；热量超标，“有点超了，晚餐控制一下”。生成规则放在后端，前端只管展示。这个功能非常有“产品感”，展示时自然加分。

5.3 亮点三：本地缓存设计

小程序端把用户基本信息、今日已记录的数据缓存在storage中，进入首页时先渲染缓存再请求接口更新。这个设计在弱网环境下效果明显，更重要的是，它展现了你对小程序性能优化的理解。实现时注意在用户修改档案或提交新记录后同步更新缓存，避免数据不同步。

6. 答辩前你应该准备的几个问题

答辩不会因为你把代码跑起来就给你高分，评委更关心的是“你能不能把系统里的设计决策讲清楚”。以下是我总结的高频追问和应对思路：

“为什么不用云开发而自建后端？”先说明云开发的优点，再讲你的考量：自建后端可以完整展示后端设计能力（表结构设计、接口设计、业务逻辑实现），同时便于扩展到其他端；云开发适合快速原型验证，但不是本系统的核心架构诉求。

“热量计算公式的依据是什么？”直接回答Mifflin-St Jeor公式，这是目前应用最广泛的基础代谢率估算公式，然后分别解释男性和女性公式参数差异的来源。能讲清这个公式，就能证明你确实研究过营养学基础，而不是随便找一个数字。

“如果用户记录的数据不准确怎么办？”这个问题考察你的容错设计能力。可以回答：系统支持食物库的持续维护更新，管理员可修正错误食物数据；用户可删除和修改历史记录；未来可接入图像识别或条码扫描功能减少手工录入误差。即使你只做了前两项，这样的回答也能体现你的产品思维。

“项目的扩展方向？”给出三个方向：接入智能设备（手环/体脂秤）数据、营养师在线咨询模块、基于用户习惯的智能推荐。不要说得太远，紧扣现有架构可以扩展的范围，表明你的项目有清晰的可生长性。

7. 一些实在话

做毕设这件事，最忌讳的是总想着憋一个大招，最后连基础功能都没做完。基于微信小程序的膳食健康管理系统，它的完成度比复杂度更重要。先把记录、计算、分析这条主链路跑通，把数据做得真实、图表做得好看，再去想亮点功能的事情。我见过太多同学一开始就计划做智能识别、做社区、做消息推送，最后连基础的食物记录都做得不完整，答辩现场演示到一半就卡壳。

另外建议你每天写一点开发日志，不用长，两三句话即可，记录今天做了什么、遇到什么问题、怎么解决的。这个习惯在写毕业设计说明书和准备答辩PPT时会有巨大帮助——你不需要靠回忆拼凑开发过程，翻日志就能想起来每一个决策的前因后果。同时，把项目部署到服务器上，给小程序配置好合法域名，哪怕答辩是在教室做演示，一个能通过真机访问的系统也比只在开发者工具里能跑的系统更有说服力。

我在做这个项目的过程中最深的一个体会是，很多看起来复杂的系统，只要把它拆成一条清晰的业务链路，然后一步一步补齐每一个环节，其实并没有想象中那么难。饮食记录这个领域，数据库表结构简单清晰，营养计算逻辑有明确的标准可依据，小程序端的界面模式也有大量成熟案例可参考。沉下心按主链路推进，每一天都在往终点靠近，这个过程本身就是做毕业设计最有价值的部分。