基于Python的Django膳食健康系统毕设全流程开发指南

一到毕业设计选题季，总有人来问我什么方向既不至于太简单、又能体现工作量，还方便扩展。我通常会给三个参考标准：业务逻辑要完整闭环、数据层要有真实计算、界面要有看得见的展示效果。按这个标准来看，基于Python的Django膳食健康系统几乎是教科书级别的毕设选题——它天然自带用户体系、数据采集、热量计算、营养分析、报告展示这几大模块，既能体现后端设计能力，又不会像电商、秒杀系统那样陷入并发和订单状态的泥潭。这篇博文就围绕这个项目，完整梳理从需求拆解、数据建模、核心功能实现，到管理后台、远程调试和部署上线的全过程，帮你把整条技术链路一次打通。

1. 为什么用Django做膳食健康系统：毕设选题逻辑与功能边界拆解

1.1 膳食健康系统为什么是毕设的"黄金选题"

先聊选题。膳食健康系统在毕设里属于"业务深度适中、技术覆盖面广"的典型代表。它不像纯CMS系统那样增删改查一眼望到头，也不像推荐系统那样依赖大量数据和复杂算法。它的核心业务——饮食记录、热量统计、营养素分析——恰好落在Web开发能力和数据分析能力的交叉点上，评委一眼就能看出你的系统到底有没有实际意义。

另外一点很务实：膳食健康系统的数据来源非常可靠。食材营养数据可以取自公开的食物成分表，不需要你自己造数据，也不涉及隐私合规问题。用户输入身高、体重、年龄、活动量，系统算出基础代谢和每日推荐摄入，再和用户的饮食记录做对比，生成健康建议——这个逻辑链条清晰、可解释性强，答辩的时候几乎不会被问倒。

1.2 核心用户角色与功能边界

一个完整的膳食健康系统，至少要覆盖两类角色：C端用户和后台管理员。千万注意，很多毕设系统只做用户端，后台全交给Django自带Admin，这虽然省事，但工作量显得单薄。我建议在项目里明确拆出管理端的功能边界。

用户端功能我建议锁定在这几块：

• 注册登录：用户名密码注册，Django自带认证基本够用。
• 个人健康档案：身高、体重、年龄、性别、活动强度，这些是热量计算的输入参数。
• 食材库浏览：按分类查看食材，搜索食材，查看每100克的热量、蛋白质、脂肪、碳水。
• 饮食记录：选择餐次（早餐/午餐/晚餐/加餐）、选择食材、填写份量，记录到对应日期。
• 每日统计：当天摄入总热量、三大营养素汇总、和推荐值的对比。
• 历史记录：按日期查看过去的饮食记录，支持修改和删除。

管理端功能可以这样设计：

• 食材库管理：新增、编辑、禁用食材，维护营养数据。
• 用户管理：查看用户列表、查看用户健康档案、禁用异常账号。
• 健康数据概览：简单的统计数据，比如注册用户数、今日记录数、热门食材Top10。

这套功能边界划下来，你的系统才称得上"完整"。很多同学只做了用户端就开始写论文，结果第二章功能需求分析写得干巴巴的，因为本身就没几个功能可写。

1.3 技术选型为什么是Django

技术选型这块，我见过用Flask硬写的，也见过用Spring Boot硬啃的。Flask太轻，很多东西要从零搭，工作量容易失控；Spring Boot对Python基础薄弱的同学来说又是另一个语言体系。Django的好处在于：自带的ORM省去大量SQL编写、自带Admin后台直接提供管理界面雏形、自带用户认证体系和CSRF防护，这些恰好是毕设系统最需要又最容易被扣分的点。

配合Python生态做营养计算也顺手。热量和营养素计算本质上就是浮点数运算加逻辑判断，完全可以用Python写成一个独立的服务层模块，和Django视图解耦。这样在论文里可以单独写"算法设计"一章，显得有深度。

2. 项目骨架怎么搭：目录规划与核心配置的一次到位方案

2.1 项目目录结构规划

拿到源码第一件事，先把目录结构看懂。这里给出一种常见的Django项目布局方式，我建议你也按这个思路组织自己的代码：

health_system/ # 项目根目录 ├── manage.py ├── requirements.txt ├── config/ # 项目配置目录 │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ ├── wsgi.py │ └── asgi.py ├── apps/ │ ├── users/ # 用户模块 │ ├── foods/ # 食材库模块 │ ├── diets/ # 饮食记录模块 │ └── reports/ # 营养分析与报告模块 ├── static/ # 静态文件 ├── media/ # 用户上传文件 └── templates/ # 模板目录

这里把项目名放在config目录而不是直接用项目名做包名，一个直接好处是后续部署时改动更少，另一个好处是应用都收拢到apps目录下，逻辑边界清晰。模块划分我用了四个：users、foods、diets、reports。有人会问，reports模块是不是多余？我的看法是，营养分析这部分逻辑相对独立，包括推荐摄入量计算、营养素达标率判断、建议文本生成，拆出来单独放一个模块，后续扩展推荐算法也好、生成报告也好，都不会污染饮食记录的核心代码。

2.2 settings.py 里最容易忽略的几个配置

Django项目新建之后，settings.py默认配置只在开发场景可用，真要跑膳食健康系统，有几个地方必须先改。

第一个是INSTALLED_APPS。除了默认应用，务必加入你要用的第三方应用和自己创建的app：

INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'apps.users', 'apps.foods', 'apps.diets', 'apps.reports', ]

第二个是数据库配置。默认是SQLite，开发阶段够用，但如果你打算部署到服务器上跑，建议直接上MySQL。配置时有一组经典的参数：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'health_system', 'USER': 'root', 'PASSWORD': '你的密码', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', }, } }

utf8mb4这个一定要加，否则食材名称里万一有生僻字或者特殊符号，写入数据库会报错。

第三个是AUTH_USER_MODEL。只要你打算给用户加健康档案字段，就必须自定义用户模型，而且必须在第一次迁移数据库之前就定义好。这是Django里一个著名的约束：中途换用户模型非常痛苦。所以我要强调，项目一开始就要定义好扩展用户模型，哪怕现在只是加一个phone字段。

2.3 虚拟环境与依赖管理

依赖方面，requirements.txt要控制好。一个膳食健康系统最核心的依赖其实不多，我给一个极简清单：

Django>=4.2,<5.0 mysqlclient>=2.2.0 Pillow>=10.0.0 django-simpleui>=2023.7.1

如果你没有用MySQL，就把mysqlclient这行去掉；如果不打算美化Admin，django-simpleui也可以去掉。Pillow则是为了处理用户头像上传之类的问题，属于常用依赖。

这里想特别提醒：不要一股脑把环境里所有包都pip freeze进requirements.txt，很多是无关的传递依赖，别人拿到你的源码安装时反而容易版本冲突。手工维护所需依赖列表，才是负责任的做法。

3. 食物、档案、记录三张表：数据模型设计与热量计算的来龙去脉

3.1 三张核心表的结构设计

膳食健康系统里最重要的三张表：用户健康档案、食材表、饮食记录表。理解这三张表的关系，整个数据库设计就通了。

用户健康档案和Django自带的User是一对一关系，字段设计如下：

class HealthProfile(models.Model): user = models.OneToOneField( settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name='health_profile', verbose_name='用户' ) gender = models.CharField('性别', max_length=1, choices=[('M', '男'), ('F', '女')]) height = models.FloatField('身高(cm)') weight = models.FloatField('体重(kg)') birth_date = models.DateField('出生日期') activity_level = models.CharField( '活动强度', max_length=1, choices=[ ('1', '久坐'), ('2', '轻度活动'), ('3', '中度活动'), ('4', '高强度活动') ] ) created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now=True)

食材表字段设计要点是营养素数据要统一以"每100克可食部"为基准：

class Food(models.Model): name = models.CharField('食材名称', max_length=100, unique=True) category = models.CharField('分类', max_length=50, db_index=True) calorie = models.FloatField('热量(kcal/100g)') protein = models.FloatField('蛋白质(g/100g)') fat = models.FloatField('脂肪(g/100g)') carbohydrate = models.FloatField('碳水化合物(g/100g)') fiber = models.FloatField('膳食纤维(g/100g)', default=0) is_active = models.BooleanField('是否启用', default=True)

饮食记录表则把用户、食材、餐次、份量关联起来，同时冗余存储一份营养快照：

class DietRecord(models.Model): user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name='diet_records') food = models.ForeignKey(Food, on_delete=models.PROTECT, verbose_name='食材') meal_type = models.CharField('餐次', max_length=1, choices=[('B', '早餐'), ('L', '午餐'), ('D', '晚餐'), ('S', '加餐')]) quantity = models.FloatField('份量(g)', default=100) record_date = models.DateField('记录日期', db_index=True) calorie = models.FloatField('热量(kcal)', editable=False) protein = models.FloatField('蛋白质(g)', editable=False) fat = models.FloatField('脂肪(g)', editable=False) carbohydrate = models.FloatField('碳水(g)', editable=False) created_at = models.DateTimeField(auto_now_add=True)

注意两个设计细节。第一，DietRecord里冗余存储了营养素快照，这样做的原因是：如果食材表里某个食材的热量数据后续被修正，历史饮食记录不应该跟着变——饮食记录是对"当时吃了什么"的事实记录，必须保持稳定。第二，外键用了on_delete=models.PROTECT，这比CASCADE更安全，防止有人误删被引用过的食材导致历史记录静默丢失。

3.2 推荐摄入量是怎么算出来的：BMR与TDEE

整个系统的灵魂是热量计算。如果只是把用户吃的热量加起来显示一个数字，那这个系统就没有专业含量。正确做法是至少要算出用户的每日推荐摄入量，然后和实际摄入做对比。

最常用的算法是Mifflin-St Jeor公式。男性基础代谢BMR：

BMR = 10 * 体重(kg) + 6.25 * 身高(cm) - 5 * 年龄 + 5

女性基础代谢BMR：

BMR = 10 * 体重(kg) + 6.25 * 身高(cm) - 5 * 年龄 - 161

算完BMR后，再乘以活动系数得到TDEE，也就是每日总能量消耗：

年龄用当前日期减去出生日期换算，这一步千万别用字符串截取的方式去处理，直接用date对象计算：

from datetime import date def calculate_age(birth_date): today = date.today() return today.year - birth_date.year - ((today.month, today.day) < (birth_date.month, birth_date.day))

3.3 三大营养素的推荐比例：不只是热量

热量之外，还必须考虑营养素结构。国内常用参考是中国居民膳食营养素参考摄入量（DRIs），其中宏量营养素的供能比例建议大致是：碳水化合物50%-65%，蛋白质10%-20%，脂肪20%-30%。

换算成克数需要引入供能系数：

碳水每克提供4kcal 蛋白质每克提供4kcal 脂肪每克提供9kcal

假设某用户TDEE是2000kcal，按碳水55%、蛋白质15%、脂肪30%分配，则目标摄入量为：

碳水目标 = 2000 * 0.55 / 4 = 275g 蛋白质目标 = 2000 * 0.15 / 4 = 75g 脂肪目标 = 2000 * 0.30 / 9 = 66.7g

这段计算逻辑应该封装成一个独立函数，接收TDEE，返回三大营养素推荐克数。why?因为后面写报告模块、健康建议模块都要复用，拆得越干净，维护成本越低。同时注意这些推荐值是比例，不同健康目标（减脂、增肌、维持）比例要动态调整，这是后面扩展的伏笔。

4. 用户端核心功能串讲：饮食记录、统计分析和建议生成的落地写法

4.1 饮食记录的增删改查与列表页

饮食记录模块是用户每天都会用的功能，我们把它做成"按日期聚合"的形式。用户进入记录页，默认看到今天的记录列表和统计卡片，也可以切换日期查看历史记录。

记录创建的表单核心就三个字段：食材、餐次、份量。这里有一个好用的交互优化：在模板里用Django的select组件下拉选择食材，选完食材后自动带出该食材每100g的热量供用户参考，避免用户瞎填。前端可以通过简单的JavaScript监听select的change事件，从data属性中读取热量并展示。

创建记录的核心视图逻辑大概是：

def record_create(request): if request.method == 'POST': form = DietRecordForm(request.POST) if form.is_valid(): record = form.save(commit=False) record.user = request.user record.save() return redirect('diets:record_list') else: form = DietRecordForm() return render(request, 'diets/record_form.html', {'form': form})

这里最关键的技巧在DietRecordForm的save流程里。食材选好、份量填好之后，热量和营养素快照的计算应该在模型层的save方法里自动完成，而不是在视图里计算再赋值。这样不管从哪个入口创建记录，数据都不会漏算。

def save(self, *args, **kwargs): if not self.pk: ratio = self.quantity / 100.0 self.calorie = round(self.food.calorie * ratio, 2) self.protein = round(self.food.protein * ratio, 2) self.fat = round(self.food.fat * ratio, 2) self.carbohydrate = round(self.food.carbohydrate * ratio, 2) super().save(*args, **kwargs)

4.2 每日统计的聚合查询：一个ORM的经典用法

每日统计是整个系统最核心的查询。用Django ORM的aggregate可以一次性把某天摄入的总热量、总蛋白质、总脂肪、总碳水全取出来：

from django.db.models import Sum daily_stats = DietRecord.objects.filter( user=request.user, record_date=target_date ).aggregate( total_calorie=Sum('calorie'), total_protein=Sum('protein'), total_fat=Sum('fat'), total_carbohydrate=Sum('carbohydrate'), )

聚合返回的字典中，如果当天没有任何记录，所有值都是None，所以页面展示前要做默认值处理。这一步很多同学会忽略，结果页面直接显示None，非常影响观感。建议统一处理为0.0。

4.3 达标率计算与建议生成规则

有了实际摄入和推荐摄入，接下来就是健康建议模块。我的实现思路是写一个独立的Calculator服务类，输入用户档案和当天统计数据，输出一份结构化分析结果。

class NutritionAnalyzer: def __init__(self, profile, daily_intake): self.profile = profile self.tdee = self._calc_tdee() self.targets = self._calc_targets(self.tdee) self.intake = daily_intake def get_analysis(self): return { 'tdee': self.tdee, 'target': self.targets, 'intake_ratio': self._calc_ratio(), 'suggestions': self._generate_suggestions(), }

建议生成规则可以这样设计，用简单的阈值判断：

• 实际摄入热量低于推荐值80%，给出"摄入不足，可能导致精力下降"类建议。
• 高于推荐值120%，给出"热量超标，建议增加运动消耗"类建议。
• 碳水供能比高于65%，建议适当减少精制碳水摄入。
• 蛋白质供能比低于10%，建议增加优质蛋白来源，如蛋、鱼、瘦肉。
• 脂肪供能比高于30%，建议减少油炸食品和高脂食物。

这些规则看似简单，但已经能用真实数据支撑建议内容，而不是写死文案。答辩时你可以说这是"基于规则的营养评估引擎"，后续还能扩展更多维度的判断。

4.4 数据可视化：比起表格，图表更能打动评委

纯粹的数字列表说服力有限，加上图表展示，整个系统的完成度立刻提升一个档次。建议你用ECharts在饮食记录页放两个图：一个是近7天热量摄入的柱状趋势图，对比每日推荐摄入线；一个是今日三大营养素供能占比的环形图。

ECharts通过CDN引入即可，不需要额外打包工具。Django视图里把近7天数据组装成JSON传给模板：

last_7_days = [] labels = [] for i in range(6, -1, -1): day = date.today() - timedelta(days=i) labels.append(day.strftime('%m-%d')) stats = DietRecord.objects.filter(user=request.user, record_date=day).aggregate(total=Sum('calorie')) last_7_days.append(round(stats['total'] or 0, 2))

模板中用JSONScript将数据渲染到页面，然后ECharts正式初始化图表。这一套流程跑通后，系统的可视化展示能力会非常出彩。

5. 管理端怎么做才不拉胯：Admin定制、权限控制与食材库维护

5.1 Django Admin自定义：三行代码让后台更专业

自带的Django Admin虽然开箱即用，但默认界面比较朴素。这里有两个方向：一是引入django-simpleui或django-jet做整体美化，二是通过在admin.py里配置list_display、search_fields、list_filter来提升列表页的实用性。

我的建议是两个都做。先看代码层面：

from django.contrib import admin from .models import Food @admin.register(Food) class FoodAdmin(admin.ModelAdmin): list_display = ('name', 'category', 'calorie', 'protein', 'fat', 'carbohydrate', 'is_active') search_fields = ('name', 'category') list_filter = ('category', 'is_active') list_editable = ('calorie', 'is_active') list_per_page = 20

list_editable这个配置非常实用，可以直接在列表页修改热量和启用状态，省得每改一个食材都进编辑页。对毕设这种演示场景来说，这个细节评委是能看到的。

5.2 管理端权限控制：Admin天然就够了

很多同学在管理端权限上过度设计，单独写一套登录和权限判断，其实浪费太多时间。Django Admin自带的用户/组/权限体系对你这个需求已经足够。

要做的事情只有两件：

第一，创建超级用户：

python manage.py createsuperuser

第二，保证食材数据只能由管理员维护。这一点Admin天然满足。如果你的系统里还有独立的"营养师"或者"运营人员"页面，那可以创建staff用户并分配指定权限。具体操作是进入Django Admin的用户编辑页，把用户设为is_staff，再在"用户权限"里勾选对Food、DietRecord等模型的新增、修改、删除权限。

需要注意的是，如果普通用户也是Django的User模型，那么他们实际上也可以尝试访问/admin路径。解决办法是在Admin里不给普通用户分配任何staff权限，他们登录后台会直接403。这个默认行为不需要额外开发。

5.3 食材库批量导入：一个容易被忽略但特别加分的小功能

手工录入上百条食材数据是不现实的。推荐用Django Admin的admin action写一个"从CSV批量导入食材"的功能。

大致的实现思路是：在管理后台提供一个CSV上传入口，读出Excel或CSV文件中的每一行字段，然后批量更新或创建Food表记录。这个属于自定义管理命令（management command）的典型场景，代码可以参考下面的结构：

class Command(BaseCommand): help = '批量导入食材数据' def add_arguments(self, parser): parser.add_argument('csv_file', type=str) def handle(self, *args, **options): with open(options['csv_file'], encoding='utf-8-sig') as f: reader = csv.DictReader(f) for row in reader: Food.objects.update_or_create( name=row['名称'], defaults={ 'category': row['分类'], 'calorie': float(row['热量']), 'protein': float(row['蛋白质']), ... } )

注意csv文件的编码要用utf-8-sig，否则Excel另存的CSV文件里有BOM头，第一列列名会多出\uFEFF字符，导致解析错误。这个坑我踩过不止一次，实际导入前最好先用文本编辑器确认编码。

6. 从本地到远程：调试流程、常见报错和部署上线实录

6.1 第一次把项目跑起来的完整流程

无论你是自己写的还是拿了别人源码，在本地跑通一个Django项目，流程是标准化动作。按顺序来：

1. 创建Python虚拟环境并激活。
2. 安装依赖：pip install -r requirements.txt。
3. 修改settings.py里的数据库连接信息（用户名、密码、库名）。
4. 在MySQL里创建数据库，字符集选utf8mb4。
5. 执行数据库迁移：python manage.py makemigrations和python manage.py migrate。
6. 创建超级用户：python manage.py createsuperuser。
7. 启动开发服务器：python manage.py runserver。
8. 打开浏览器访问 http://127.0.0.1:8000 ，先登录Admin确认后台正常，再访问用户端页面。

如果第八步页面白屏或报错，绝大多数情况出在第三步和第五步之间。先看控制台错误日志，英文报错里最常见的是Unknown column，那就是迁移没执行全；Access denied for user，说明数据库账号密码不对。

6.2 三个高频报错和对应的解决方案

第一个高频报错是ModuleNotFoundError: No module named 'mysqlclient'。Windows环境下用pip直接安装mysqlclient经常失败，建议提前装好Microsoft C++ Build Tools，或者改用PyMySQL并配置：

import pymysql pymysql.install_as_MySQLdb()

第二个高频报错是django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module。这个通常就是上面的mysqlclient/pymysql没装好导致的，按第一种方案处理即可。

第三个高频报错是静态文件404。开发环境下settings.py里要有：

STATIC_URL = '/static/' STATICFILES_DIRS = [BASE_DIR / 'static']

如果Admin样式加载不出来，还得确保django.contrib.staticfiles在INSTALLED_APPS里，以及项目根目录的URL中不要拦截了static路径。这个排查思路能解决90%的静态文件问题。

6.3 远程调试与协作：不是只能靠runserver

项目交付里提到的远程调试，本质上是帮助对方把项目在本地或服务器上跑通、及时定位配置问题。作为开发者，我有几个行之有效的远程协作手段。

最常见的是远程桌面协助。你让对方打开远程协助工具，你直接在他电脑上操作，把虚拟环境、依赖、数据库、迁移一步步配好。这种方式对小白的友好度最高，因为你在操作的过程中可以顺便讲清楚每一步在做什么。

第二种方式是SSH登录服务器排查。如果项目已经部署到服务器上，你用SSH连上去直接看系统日志：

journalctl -u gunicorn -f

有日志在手，排查速度比你远程让对方截图快得多。刚才说的那些ModuleNotFoundError、数据库连接失败，日志里都会原原本本写出来。

第三种方式是指导对方拍照/截图错误终端，根据报错信息定位问题。现代浏览器的开发者工具里，Network面板能直接看到哪个请求返回500或404。远程调试最核心的不仅仅是把问题修好，而是要让对方明白这个错误是怎么产生、以后遇到类似问题怎么排查。

6.4 上线部署：gunicorn + Nginx 的标准姿势

如果只是交本地项目，runserver就能应付答辩演示。但如果想让系统在公网或局域网里跑起来，最好还是部署一次。部署方案我推荐 gunicorn + Nginx 的组合。

首先关闭DEBUG模式，配置ALLOWED_HOSTS：

DEBUG = False ALLOWED_HOSTS = ['你的服务器IP或域名']

然后收集静态文件：

python manage.py collectstatic

用gunicorn启动项目：

gunicorn config.wsgi:application -b 0.0.0.0:8000

Nginx里做反向代理和静态文件托管即可。整个部署过程，我建议放在系统功能全部跑通之后再动手，因为部署涉及到的变量非常多，项目本身有bug时部署排查会特别痛苦。部署成功后的截图放进论文的"系统实现"部分，是很加分的材料。

7. 从"能跑"到"能答辩"：二次开发方向与论文素材沉淀

7.1 三个低成本高收益的扩展方向

一个能跑的系统只是打底，想在答辩中脱颖而出，得有增量亮点。我推荐三个方向，难度递增，按自己的能力选择。

第一个扩展方向：菜谱推荐。在食材库之上增加"推荐菜谱"功能，根据用户已选食材和当日营养摄入差额，推荐合适菜谱。技术上其实就是在菜谱表里加一个标签字段，然后按匹配度排序过滤。

第二个扩展方向：健康周报。每周自动生成一份营养摄入汇总报告，通过邮件发送给用户。技术点涉及定时任务和邮件发送，Django里可以用django-crontab或者Celery实现。考虑到毕设体量，django-crontab就够了，不需要引入Celery这么重的框架。

第三个扩展方向：食物识别。用户拍一张食物照片，识别出是哪种食材，自动带入热量计算。这就跳出了纯Web开发的范畴，需要接API或者自己训练一个简单分类模型。如果你对机器学习有一定基础，这个方向会让整个系统的技术含量上升一个档次。

7.2 写论文时的重点章节和答辩常见问题

论文的章节结构通常围绕软件工程的标准流程来写，核心内容包括：选题背景与研究意义、国内外研究现状、需求分析（功能需求与非功能需求）、系统概要设计（架构图、模块划分）、数据库设计（ER图、表结构说明）、系统详细设计（核心功能流程图与实现）、系统测试（功能测试用例表、测试结果）。

写系统详细设计的时候，热量计算部分一定要写清楚公式来源和计算过程，三大营养素供能比的推荐标准要注明参考依据。

答辩时评委大概率会问这几个问题，提前准备好话术：

• 为什么选Django而不是Flask？这题说的就是开发效率、内置组件、生态成熟。
• 推荐摄入量的公式依据是什么？把Mifflin-St Jeor公式和活动系数表背熟。
• 如果用户连续三天热量超标，系统会给出什么建议？这题考察你对业务逻辑的理解，把建议生成规则讲清楚即可。
• 如何保证用户密码安全？Django内置的PBKDF2算法、加盐哈希，讲出这两个词就行。
• 数据库为什么这样设计？从外键约束、冗余快照、索引三个角度回答。

拿到一套现成源码之后，最好的打开方式不是直接把它当黑盒交给老师，而是逐行理解数据模型、视图、模板之间的关系。哪怕只改掉一个模块，在答辩时你都讲得更理直气壮，因为你真的搞懂了。

7.3 我在多次实操中的几点体会

最后分享几个带学生做这类项目时反复出现的问题。第一个是迁移数据库的时间点：一定要在写任何业务逻辑之前把自定义用户模型配置好，否则中途改模型要清库重来，等于白干。第二个是食材数据的单位一致性：数据库里所有营养素都以100克为基准，前端展示也要用100克说事，一旦某个地方用了"一份"的概念，统计就会失真。第三个是切忌在答辩前一刻换数据库：很多人开发用SQLite，答辩前临时切MySQL，结果一堆字段类型不兼容报错。要换就早换，要么就全程统一。

做膳食健康系统这类毕设，本质上是在训练自己"从需求到落地"的完整思维链条：先搞清楚为谁做、做什么，再设计数据结构，然后通过代码把数据和业务串起来，最后用部署和测试验证系统的可靠性。这套思路在任何Web开发项目里都是通用的，做完这个项目，你获得的不只是一份可以提交的代码和论文，还有一套以后能迁移到其他技术栈的工程方法论。