奥力星科技兄弟们，今天聊个毕业设计里特别务实的话题：怎么用Django+微信小程序，把一个“运动饮食健康生活系统”从零到一完整落地。我去年带学生做毕设时，这个题目被翻牌子的频率极高，因为方向贴近生活、技术栈主流、工作量适中，同时又能把Web后端、小程序前端、数据库设计、部署上线这些关键能力全部串起来。这篇文章我不打算讲虚的，直接结合一个真实项目的完整源码、LW（论文文档）和部署说明，把整体设计思路、核心表结构、登录认证细节、小程序端实现、服务器部署流程，以及我实操中踩过的坑，一五一十全部分享出来。适合正准备做相似选题的同学，也适合工作后想拿这个项目练手熟悉全栈开发的开发者。
整个系统的业务并不复杂：用户注册登录后，可以记录每天的运动数据（跑步、骑行、健身等），记录每餐的食物摄入情况，系统根据录入的数据给出热量统计、运动消耗、营养均衡度等健康报告。听起来简单，但真正把每个环节都做扎实，涉及的知识点其实很密集。这篇文章用的项目是基于Django 3.2 + Django REST Framework + 微信小程序原生框架开发的，数据库用的MySQL，部署层面用的宝塔面板。下文我会尽量把关键代码和配置都贴出来，方便你直接对照操作。
1. 项目整体设计与技术选型思路
1.1 为什么偏偏是Django + 微信小程序
选题阶段，很多学生会在Spring Boot、SSM、PHP和Django之间纠结。我的建议很直接：如果目标是快速出活、逻辑清晰、后端代码好维护，Django几乎是毕设项目的最优解。原因有两个。第一，Django自带的Admin后台可以直接用来做数据管理，对毕设演示来说，你可以少写一大堆后台管理页面，把精力集中在业务模块上；第二，Django的ORM极其好用，模型一改，迁移命令一跑，数据库表就同步了，这对毕设期间频繁改表结构的场景来说，省下来的时间不是一星半点。
微信小程序端则是目前做“轻量级C端应用”的标配。不用装App，微信里扫码即用，开发和审核流程都很成熟，而且小程序端的UI组件和API设计得很统一，只要你会基础的JavaScript，基本上就能把页面撸出来。最关键的在于，小程序生态里关于登录、支付、数据请求等都有官方标准范式，网上资料齐全，遇到问题基本搜得到答案，对新手非常友好。
1.2 系统核心业务模块怎么划分
我习惯先画业务模块图再动手写代码。这个系统我把它拆成了六大模块：用户管理模块、运动记录模块、饮食记录模块、健康统计模块、数据可视化和个人中心。
- 用户管理：微信登录、Token鉴权、个人资料维护、BMI计算。
- 运动记录：用户录入运动类型（跑步/骑行/游泳等）、时长、距离、消耗热量，系统自动估算消耗卡路里。
- 饮食记录：用户按早/中/晚餐记录食物名称、分量，系统根据内置食物热量库计算摄入卡路里。
- 健康统计：按天/周/月维度汇总摄入与消耗的差值、营养元素占比（碳水、蛋白质、脂肪）。
- 数据可视化：小程序端用ECharts或小程序自带canvas绘制柱状图、折线图。
- 个人中心：历史记录列表、修改个人信息、清空缓存、反馈建议。
这些模块从用户视角看是完整的，从开发量看也适中，不会出现“工作量不足”或“工作量爆炸”两个极端。而且每个模块都能在答辩时拿出来单独讲，逻辑清晰好表达。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库表设计与后端核心接口拆解
2.1 数据库表设计：如何保证可扩展性
数据库设计是整个项目的根基。表结构设计得合理，后面写业务逻辑就是顺水推舟；设计得不合理，后期改起来会让人怀疑人生。我设计了几张核心表，简单展开一下。
用户表是对Django默认User模型的一对一扩展，存储用户的微信openid（注意这里不能只存昵称头像）、身高、体重、年龄、性别、目标体重。之所以用OneToOneField扩展而不是直接改原表，是为了不破坏Django自带的认证体系，这个习惯在企业项目里也是通用的。
运动记录表是高频操作的表，核心字段包括用户外键、运动类型、运动日期、运动时长（分钟）、运动距离（公里）、消耗热量（千卡）、备注。关于热量消耗，常用的是MET（代谢当量）估算公式：消耗热量（千卡）= MET值 × 体重（kg） × 时间（小时）。例如跑步（8公里/小时）的MET值是8.3，一个60kg的人跑30分钟，消耗就是8.3 × 60 × 0.5 = 249千卡。我建议把这个计算逻辑放在后端完成，前端传原始数据即可，避免用户数据篡改。
饮食记录表需要关联食物表。食物表要维护一个热量库，记录常见食物的热量、蛋白质、脂肪、碳水含量。饮食记录表则记录用户某餐吃了哪个食物、吃了多少克，系统根据食物表中100g对应的营养素含量计算出实际摄入。这里有个坑，食物表的数据需要一定的基础数据量，我直接用了一部分公开的《中国食物成分表》的数据并做成了SQL文件导入，大概有200多条常用食物记录，完全够演示了。
健康统计表这个看需求。我的做法是，不做物理表，而是通过后端接口实时聚合查询运动表和饮食表数据。为什么？因为毕设的数据量级根本不需要提前聚合，实时查询保证数据绝对准确，还省得维护冗余字段。只有当你做千万级用户的商业系统时，才需要考虑用统计表来做预聚合。
2.2 RESTful接口设计：不能只写增删改查
后端采用的是Django REST Framework（DRF），这是Django生态里做API最成熟的方案。我定义接口遵循一个原则：面向场景而非面向数据表。就是说，接口不是“运动记录表的增删改查”，而是“记录一次运动”“查询某天运动汇总”“查询运动历史趋势”。这能让你在答辩时讲出设计感。
完整接口清单大概如下：
- POST /api/auth/login：微信登录，接收code换取openid，返回token。
- GET /api/user/profile：获取当前用户信息。
- PUT /api/user/profile：修改个人资料。
- GET /api/sport/records：获取运动记录列表（可分页、按日期过滤）。
- POST /api/sport/record：新增运动记录。
- DELETE /api/sport/record/{id}：删除运动记录。
- GET /api/diet/records：获取饮食记录。
- POST /api/diet/record：新增饮食记录。
- GET /api/food/search?keyword=：食物热量库搜索。
- GET /api/health/summary?date=：某天健康汇总（摄入、消耗、差值、营养占比）。
- GET /api/health/trend?days=7：近N天趋势数据。
这里特别想提一下认证方式。我选了JWT（JSON Web Token）而不是Django默认的Session。原因是小程序端没有Cookie机制，用Token更自然。DRF搭配simplejwt库，实现起来非常顺手。用户首次通过wx.login拿到临时code，后端拿去微信接口换取openid和session_key，用openid去用户表查找，不存在则自动注