做购物网站的项目尤其是“减肥减脂轻食品”这种垂直品类第一反应往往会落入“商品CRUD 购物车 订单”这种模板思路。但真正把这个项目从能跑做到好用里面要抠的细节比想象中多得多——选型纠结、数据建模、库存扣减、热量计算、部署上线每一层都有值得展开的东西。这篇我把整个项目的设计与实现过程拆开讲从需求分析一直讲到部署重点落在“为什么这么做”和“实际踩过的坑”上。如果你正在用Python做Web方向的项目或者准备拿这类电商系统练手应该能从里面找到不少能直接抄作业的东西。先说一个我的判断这类轻食品电商项目和普通电商最大的区别不在交易流程而在“减脂”这个属性。用户买全麦面包、鸡胸肉、代餐粉核心诉求不是“能吃饱”而是“精准控制热量摄入”。所以只做商品展示和下单是不够的还要把营养数据、热量计算、甚至用户健康档案纳入系统。这也是这个项目真正有价值、有差异化、值得写进设计文档的部分。1. 先想清楚轻食品电商到底要解决什么问题1.1 垂直品类的核心需求拆解减肥减脂食品这个品类用户在购物过程中的决策逻辑和买普通零食完全不同。普通用户买零食看口味、看品牌、看价格减脂用户更关注的是一份多少卡路里、蛋白质含量够不够、碳水高不高、脂肪是不是优质脂肪。这意味着商品详情页不能只放图片和价格还必须有一套结构化的营养数据表最好还能帮用户算一下“这个东西我能不能吃”。从需求优先级来看这类网站至少要具备四个层次的能力基础层商品的展示、搜索、分类、详情这个和普通电商一致。交易层购物车、订单、支付、库存管理这个也是标配。差异层营养标签、热量标注、按热量/蛋白/碳水筛选产品。增值层用户健康档案、每日热量预算、推荐菜品或套餐。很多课程项目做到第二层就结束了但真正想让它“像回事”第三层和第四层才是关键。后面我会详细讲差异层和增值层的实现思路因为这两层决定了你的项目是“一个购物网站”还是“一个减脂食品购物网站”。1.2 项目范围与技术栈的匹配确定好需求层次后再回头看技术选型就清晰了。单页面展示可以用静态页面但一旦涉及用户注册、订单、库存、健康档案就必然需要后端框架加数据库。用Python生态来做flask和django基本是绕不开的两个选项也是搜索热词里反复出现的两个框架。我的建议是如果你项目周期短、想要快速搭出原型优先用Flask它的轻量特性让你可以自由决定塞进哪些组件如果你的需求本身就包含用户体系、后台管理、ORM、迁移、表单校验这些复杂能力优先用Django因为它自带电池能把很多基础工作直接省掉。那标题里为什么是“flask-django”这种写法这种表达通常出现在课题命名里意思是两套方案都站得住。我会在下一节详细讲两者到底怎么选以及合在一起用是不是靠谱的选择。2. Flask和Django怎么选单框架为主还是真能混着用2.1 两个框架的定位差异对比先说结论对于一个购物网站项目我不推荐在同一进程里把Flask和Django混着跑更常见的合理做法是以一个框架为主另一个在独立服务中做辅助。对比维度FlaskDjango定位微框架灵活、轻量全栈框架自带ORM/Admin/Auth上手曲线低几行代码能跑一个接口中需要理解项目结构和MTV模式ORM默认无常用SQLAlchemy自带Django ORM迁移方便Admin后台需自己写或接第三方自带Admin改一改就能用适合场景小型服务、API、快速原型业务复杂、模块多、重后台的中型项目在开发效率上Django对这类带商品管理、订单管理、用户管理的项目非常友好。它自带的Admin界面可以直接拿来当运营后台用省掉一整套后台开发的工作量。Flask则胜在透明、可控适合那种你明确知道自己要什么、不想被框架约束的场景。2.2 我最终采用的组合方式那“flask-django”能不能共用我的实践是可以但要有边界。Django负责主站业务——商品、购物车、订单、用户、后台这是系统的核心Flask独立跑一个轻量服务负责辅助功能比如食材卡路里计算接口、BMR基础代谢率计算、推荐逻辑或者对接第三方营养数据源做爬虫清洗。为什么这么拆因为和营养相关的计算逻辑往往经常迭代今天用Mifflin-St Jeor公式算基础代谢明天可能换成Katch-McArdle公式后天可能想加一个AI估算热量工具。把这些易变的、独立的小模块抽出来放到Flask服务里不影响主站测试成本也低。两个服务通过HTTP接口通信Django这边用requests或httpx调用Flask的接口两边解耦得比较干净。如果你只想要一个方案我推荐主用Django。原因很直接购物网站最繁重的部分是后台管理、订单状态、数据关系这些Django都有成熟方案你不会把大量时间耗在重复造轮子上。2.3 开发环境的基础配置备忘不管选哪个框架开发环境里有几个容易踩坑的点需要提前确认Python版本建议3.10太老版本对Django新特性支持不好。虚拟环境一定要建venv或conda都行别把依赖装到全局。数据库默认用SQLite开发方便但如果你明确要上MySQL最好一开始就配好连接避免开发后期切换时被数据类型差异坑。环境变量尽量用.env文件管理数据库口令、密钥、支付接口Key都不要硬编码在源码里。Django建项目的基本操作也不复杂# 创建虚拟环境 python -m venv venv source venv/bin/activate # 安装Django pip install django # 创建项目和app django-admin startproject litefood_project cd litefood_project python manage.py startapp goods python manage.py startapp cart python manage.py startapp order python manage.py startapp user_profile3. 数据库设计从商品到订单的核心表结构3.1 领域模型建模的思路数据库设计是整个项目的地基。轻食品购物网站的核心实体包括用户、商品、商品分类、营养信息、购物车、订单、订单明细、健康档案。这里我重点讲两个容易被忽视的地方。第一个是商品和营养信息的关系。不建议把热量、蛋白质、脂肪、碳水直接塞进商品表。因为同一款商品可能有不同规格比如一盒鸡胸肉是100g装和200g装营养数据是“每100g”的标准值规划成单独的营养表会更清晰后期做营养筛查也更方便。第二个是用户健康档案和订单的关系。减脂人群有一个特殊需求记录每天的摄入量。这个可以通过“订单明细关联营养表”间接计算。用户在某个时间段内买了哪些商品每份热量是多少累加起来就是当天或近期的热量摄入估算。这种设计不需要额外做摄入记录模块就可以实现基本的热量追踪功能一举两得。3.2 核心表结构详解用Django ORM来描述这部分模型会清晰得多。下面给出核心模型示例# goods/models.py from django.db import models class Category(models.Model): name models.CharField(max_length64, uniqueTrue, verbose_name分类名称) parent models.ForeignKey(self, nullTrue, blankTrue, on_deletemodels.CASCADE, verbose_name父分类) class Meta: verbose_name 商品分类 verbose_name_plural verbose_name def __str__(self): return self.name class Product(models.Model): name models.CharField(max_length128, verbose_name商品名称) category models.ForeignKey(Category, on_deletemodels.PROTECT, related_nameproducts, verbose_name所属分类) price models.DecimalField(max_digits8, decimal_places2, verbose_name售价) stock models.PositiveIntegerField(default0, verbose_name库存) shelf_status models.BooleanField(defaultTrue, verbose_name上架状态) description models.TextField(blankTrue, verbose_name商品描述) image models.ImageField(upload_toproducts/%Y/%m/, blankTrue, verbose_name商品主图) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) class Meta: verbose_name 商品 verbose_name_plural verbose_name def __str__(self): return self.name class ProductNutrition(models.Model): product models.OneToOneField(Product, on_deletemodels.CASCADE, related_namenutrition, verbose_name关联商品) calories models.DecimalField(max_digits6, decimal_places1, verbose_name热量(kcal/100g)) protein models.DecimalField(max_digits5, decimal_places1, verbose_name蛋白质(g/100g)) fat models.DecimalField(max_digits5, decimal_places1, verbose_name脂肪(g/100g)) carbs models.DecimalField(max_digits5, decimal_places1, verbose_name碳水(g/100g)) fiber models.DecimalField(max_digits5, decimal_places1, default0, verbose_name膳食纤维(g/100g)) serving_size models.PositiveIntegerField(default100, verbose_name每份克重) class Meta: verbose_name 商品营养信息 verbose_name_plural verbose_name这里有个细节我用DecimalField而不是FloatField存价格和营养数据。电商项目最忌讳浮点数计算金额精度问题会直接在结算场景翻车。营养数据同样可能涉及热量累加用Decimal最稳。3.3 订单与购物车的状态设计购物车模型不复杂关键是在“用户维度”和“会话维度”之间做选择。登录用户可以绑User未登录用户可以用session标识。这里有个常见的坑用户登录前后购物车合并问题。简单做法是登录时把session购物车里的商品合并到用户购物车避免用户登录后购物车东西消失。订单表的状态字段建议用IntegerField加choices不要用字符串飘着# order/models.py class Order(models.Model): class StatusChoices(models.IntegerChoices): PENDING_PAYMENT 1, 待支付 PAID 2, 已支付 SHIPPING 3, 配送中 COMPLETED 4, 已完成 CANCELLED 5, 已取消 order_no models.CharField(max_length32, uniqueTrue, verbose_name订单号) user models.ForeignKey(auth.User, on_deletemodels.PROTECT, related_nameorders, verbose_name下单用户) status models.IntegerField(choicesStatusChoices.choices, defaultStatusChoices.PENDING_PAYMENT, verbose_name订单状态) total_amount models.DecimalField(max_digits10, decimal_places2, verbose_name订单总额) created_at models.DateTimeField(auto_now_addTrue, verbose_name下单时间) paid_at models.DateTimeField(nullTrue, blankTrue, verbose_name支付时间) class Meta: verbose_name 订单 verbose_name_plural verbose_name订单号不要用自增id裸奔一是容易被爬订单数据二是多表联查时不好看。我习惯用时间戳加随机串生成唯一订单号比如20250110153012XXXXXXXX这种格式保证唯一性和可读性。4. 核心功能实现商品、购物车与订单链路4.1 商品列表与筛选让减脂用户能挑东西商品列表页对普通电商只是“按分类拿数据”但对减脂食品来说还应该支持按营养指标筛选。比如用户想找“每100g热量低于150kcal、蛋白质高于20g”的鸡胸肉产品如果数据库层面不做支持前端就只能一次性拉到全部数据再过滤性能会越来越差。在后端实现搜索筛选时Django ORM的链式过滤就非常顺手# goods/views.py from django.db.models import Q def product_list(request): category_id request.GET.get(category) max_calories request.GET.get(max_calories) min_protein request.GET.get(min_protein) qs Product.objects.filter(shelf_statusTrue).select_related(nutrition) if category_id: qs qs.filter(category_idcategory_id) if max_calories: qs qs.filter(nutrition__calories__ltemax_calories) if min_protein: qs qs.filter(nutrition__protein__gtemin_protein) # 按相关度/销量/价格排序 sort request.GET.get(sort, created) sort_map { price_asc: price, price_desc: -price, calories_asc: nutrition__calories, sales: -sales_count, } if sort in sort_map: qs qs.order_by(sort_map[sort]) return render(request, goods/list.html, {products: qs})这里用到了select_related目的是一次SQL把关联的nutriton数据查出来避免模板里逐条商品再查一次营养表这在列表页尤其重要。4.2 购物车逻辑与库存扣减的坑购物车的核心操作是加购、改数量、删除、结算。表面上很简单实际最容易出问题的是“库存校验”和“并发扣减”。库存校验逻辑必须分两层。第一层在加购时校验第二层在提交订单时再次校验。因为从用户“加购物车”到“提交订单”之间可能相隔很久库存早就被其他人买光了。提交订单时发现库存不足应该提示用户哪些商品库存变动而不是整个订单提交失败。并发扣减库存如果只写朴素逻辑比如“先查库存、若大于0则扣减”在并发量上来时会超卖。Django下比较稳妥的方案是用select_for_update做行锁from django.db import transaction transaction.atomic def create_order_from_cart(user, cart_items): for item in cart_items: product Product.objects.select_for_update().get(iditem.product_id) if product.stock item.quantity: raise ValueError(f商品[{product.name}]库存不足) product.stock - item.quantity product.save() # 创建订单和订单明细...select_for_update会把涉及的商品行锁住直到事务结束。注意事务一定要用transaction.atomic包起来否则锁会在语句结束后立刻释放失去保护效果。4.3 订单提交与支付对接的注意事项支付环节对课程或演示项目来说通常不会真正接第三方支付网关但流程上要预留接口。我的建议是订单状态从“待支付”到“已支付”的变更动作抽成一个独立方法方便以后替换成真实支付回调。# order/services.py def mark_order_paid(order_no, paid_amountNone): order Order.objects.select_for_update().get(order_noorder_no) if order.status Order.StatusChoices.PENDING_PAYMENT: if paid_amount is not None and paid_amount ! order.total_amount: raise ValueError(支付金额与订单金额不一致) order.status Order.StatusChoices.PAID order.paid_at timezone.now() order.save(update_fields[status, paid_at, updated_at])还有一点容易被忽略用户连续点击“提交订单”按钮可能会生成多个重复订单。解决思路是前端按钮置灰加后端幂等校验。后端可以在订单创建接口上加入一个“防重令牌”用户点击时携带同一个令牌第一次请求成功后令牌失效第二次请求直接返回已有订单。5. 减脂场景的差异化功能卡路里计算与健康档案5.1 BMR和每日热量预算的计算逻辑减脂项目的核心差异化在于能帮用户算清楚一天到底该吃多少。这里用到的基础公式是Mifflin-St Jeor公式男性BMR 10 × 体重(kg) 6.25 × 身高(cm) - 5 × 年龄 5女性BMR 10 × 体重(kg) 6.25 × 身高(cm) - 5 × 年龄 - 161算出的BMR是基础代谢率再乘以活动系数得到TDEE每日总能量消耗。减脂用户要在这个基础上制造10%-20%的热量缺口得到每日推荐摄入热量。我单独写了一个Flask小服务来做这件事而不是堆在Django主项目里。接口设计得很简单# flask_calc/app.py from flask import Flask, request, jsonify app Flask(__name__) def calc_bmr(gender, weight_kg, height_cm, age): base 10 * weight_kg 6.25 * height_cm - 5 * age if gender male: return base 5 return base - 161 app.route(/api/calorie/budget, methods[POST]) def calorie_budget(): data request.get_json() gender data.get(gender) weight float(data.get(weight)) height float(data.get(height)) age int(data.get(age)) activity data.get(activity, moderate) deficit_ratio float(data.get(deficit_ratio, 0.15)) bmr calc_bmr(gender, weight, height, age) activity_factors { sedentary: 1.2, light: 1.375, moderate: 1.55, active: 1.725, } tdee bmr * activity_factors.get(activity, 1.55) recommend_calories tdee * (1 - deficit_ratio) return jsonify({bmr: round(bmr), tdee: round(tdee), recommend_calories: round(recommend_calories)}) if __name__ __main__: app.run(port5001)Django这边只需要在用户填写健康档案时调用这个接口拿推荐值然后存下来。用户逛商品页时每个商品的卡路里一目了然甚至能显示“相当于今日热量的百分之几”。5.2 健康档案与推荐逻辑健康档案表可以设计成一人一条活跃档案# user_profile/models.py class HealthProfile(models.Model): user models.OneToOneField(auth.User, on_deletemodels.CASCADE, related_nameprofile) gender models.CharField(max_length8, choices[(male,男),(female,女)]) height_cm models.DecimalField(max_digits5, decimal_places1) weight_kg models.DecimalField(max_digits5, decimal_places1) birth_date models.DateField(nullTrue, blankTrue) activity_level models.CharField(max_length16, defaultmoderate) daily_calorie_target models.PositiveIntegerField(nullTrue, blankTrue) updated_at models.DateTimeField(auto_nowTrue)有了这个表不只是能算预算还可以做“今日已购热量”统计。用户在订单列表里看今天买了什么后端把订单明细里每件商品的营养数据拿出来按购买数量乘一遍汇总成“今日热量/蛋白质/碳水/脂肪摄入”。这个功能在普通电商项目里没有但在减脂场景里非常亮眼也是答辩或展示时最能讲出故事的功能点。6. 实战复盘开发过程中最容易翻车的几个位置6.1 图片上传与静态文件的配置商品必须带图没图的轻食品商城完全不像话。Django的图片处理配置虽然简单但每个人第一次都容易踩坑。核心配置就三块# settings.py MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static]开发模式下要在主路由里加上media的服务from django.conf import settings from django.conf.urls.static import static urlpatterns [...] if settings.DEBUG: urlpatterns static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)另外表单要支持上传图片必须加上enctypemultipart/form-data这个很多人会忘。Python的Pillow库别忘了装否则ImageField会报错。6.2 混合架构下的会话问题如果你像我一样把营养计算交给Flask辅助服务要特别注意两个服务之间的会话隔离问题。Django的session存在数据库或Redis里Flask默认的session是签名的cookie。用户在主站登录后调Flask接口时Flask是不认识用户身份的。我的解决办法Flask服务只做“无状态计算”不在Flask层维护登录态。身份认证留在Django需要调用Flask时通过内部服务把必要参数传过去即可比如把身高体重年龄性别传到Flask接口。这样两边各自职责清楚不会打架。如果你有更复杂的需求比如Flask服务也需要鉴权可以用一个共享的API Token做服务间认证而用户的登录态始终只在主站维护。6.3 部署环节的常见问题项目开发完部署到Linux服务器上时最容易出问题的有四个地方静态文件没有用collectstatic收集页面全裸奔。数据库从SQLite切换到MySQL时字段类型不兼容。DEBUG False之后静态文件和media文件不显示了。gunicorn配置的worker数不合理内存直接被打满。部署用的gunicorn命令我的习惯配置是gunicorn litefood_project.wsgi:application \ --bind 0.0.0.0:8000 \ --workers 3 \ --timeout 60worker数一般按CPU核数×21估算。如果服务器内存不大千万别盲目multi-workerDjango的ORM和图片处理都挺吃内存的。前端再用Nginx做反向代理静态文件直接交给Nginx处理Django只处理动态请求整体压力会小很多。7. 让项目不止于作业异步任务与后续扩展思路7.1 什么时候需要引入异步任务购物网站里有几个场景天然适合异步化订单提交后发送通知、支付回调后同步订单状态、商品导入时处理图片、用户下单后记录行为日志。这些任务如果同步执行会造成不必要的接口耗时。Django生态可以直接用Celery加Redis实现异步任务。拿“下单成功发送通知”来说可以把通知任务丢到队列里接口立即返回Celery worker在后台慢慢处理。# order/tasks.py from celery import shared_task shared_task def send_order_notification(order_id): order Order.objects.select_related(user).get(idorder_id) # 假设接邮件、短信或站内信服务 message f您的订单{order.order_no}已生成请尽快完成支付。 notify_service.send(order.user.phone, message)7.2 数据统计与运营面板做完了基础交易链路之后可以再往前一步给运营加一个简单的数据看板统计每天的销售额、订单量、热销商品Top10、各分类占比。这些统计可以用Django的聚合查询直接实现比如from django.db.models import Sum, Count daily_stats ( Order.objects.filter(status__in[Order.StatusChoices.PAID, Order.StatusChoices.COMPLETED]) .values(created_at__date) .annotate(total_salesSum(total_amount), total_ordersCount(id)) .order_by(-created_at__date) )这个看板对后台运营意义很大也是向“真实可用系统”靠拢的好抓手。配合Django Admin做定制可以做到不看代码也能管商品、管订单、看统计项目完整度会明显提高。7.3 扩展方向推荐与营养追踪减脂食品购物网站再往后做有两个我很看好的方向。一个是智能推荐根据用户健康档案里的热量预算和口味偏好推荐合适的食材和套餐组合推荐逻辑可以放到Flask辅助服务里持续迭代。另一个是周期化营养追踪让用户按周查看热量摄入曲线、蛋白质是否达标再结合体重变化数据生成阶段报告。这两个方向都在“健康管理”这条线上持续加码购物本身会变成入口而非终点。对个人项目来说也是持续迭代空间最大的部分。最后分享一点个人体会做这类项目最怕一上来就埋头写CRUD写完才发现和普通电商没有任何区别。先把“减脂用户到底在乎什么”想透再倒推界面和接口设计项目做出来才会有灵魂。遇到拿不准的技术选型先动手做一个最小原型验证别在文档里纠结太久。先把主链路跑通再一步步迭代细节这才是做这类系统最务实的节奏。
基于Flask与Django的减脂食品电商网站设计与实现
做购物网站的项目尤其是“减肥减脂轻食品”这种垂直品类第一反应往往会落入“商品CRUD 购物车 订单”这种模板思路。但真正把这个项目从能跑做到好用里面要抠的细节比想象中多得多——选型纠结、数据建模、库存扣减、热量计算、部署上线每一层都有值得展开的东西。这篇我把整个项目的设计与实现过程拆开讲从需求分析一直讲到部署重点落在“为什么这么做”和“实际踩过的坑”上。如果你正在用Python做Web方向的项目或者准备拿这类电商系统练手应该能从里面找到不少能直接抄作业的东西。先说一个我的判断这类轻食品电商项目和普通电商最大的区别不在交易流程而在“减脂”这个属性。用户买全麦面包、鸡胸肉、代餐粉核心诉求不是“能吃饱”而是“精准控制热量摄入”。所以只做商品展示和下单是不够的还要把营养数据、热量计算、甚至用户健康档案纳入系统。这也是这个项目真正有价值、有差异化、值得写进设计文档的部分。1. 先想清楚轻食品电商到底要解决什么问题1.1 垂直品类的核心需求拆解减肥减脂食品这个品类用户在购物过程中的决策逻辑和买普通零食完全不同。普通用户买零食看口味、看品牌、看价格减脂用户更关注的是一份多少卡路里、蛋白质含量够不够、碳水高不高、脂肪是不是优质脂肪。这意味着商品详情页不能只放图片和价格还必须有一套结构化的营养数据表最好还能帮用户算一下“这个东西我能不能吃”。从需求优先级来看这类网站至少要具备四个层次的能力基础层商品的展示、搜索、分类、详情这个和普通电商一致。交易层购物车、订单、支付、库存管理这个也是标配。差异层营养标签、热量标注、按热量/蛋白/碳水筛选产品。增值层用户健康档案、每日热量预算、推荐菜品或套餐。很多课程项目做到第二层就结束了但真正想让它“像回事”第三层和第四层才是关键。后面我会详细讲差异层和增值层的实现思路因为这两层决定了你的项目是“一个购物网站”还是“一个减脂食品购物网站”。1.2 项目范围与技术栈的匹配确定好需求层次后再回头看技术选型就清晰了。单页面展示可以用静态页面但一旦涉及用户注册、订单、库存、健康档案就必然需要后端框架加数据库。用Python生态来做flask和django基本是绕不开的两个选项也是搜索热词里反复出现的两个框架。我的建议是如果你项目周期短、想要快速搭出原型优先用Flask它的轻量特性让你可以自由决定塞进哪些组件如果你的需求本身就包含用户体系、后台管理、ORM、迁移、表单校验这些复杂能力优先用Django因为它自带电池能把很多基础工作直接省掉。那标题里为什么是“flask-django”这种写法这种表达通常出现在课题命名里意思是两套方案都站得住。我会在下一节详细讲两者到底怎么选以及合在一起用是不是靠谱的选择。2. Flask和Django怎么选单框架为主还是真能混着用2.1 两个框架的定位差异对比先说结论对于一个购物网站项目我不推荐在同一进程里把Flask和Django混着跑更常见的合理做法是以一个框架为主另一个在独立服务中做辅助。对比维度FlaskDjango定位微框架灵活、轻量全栈框架自带ORM/Admin/Auth上手曲线低几行代码能跑一个接口中需要理解项目结构和MTV模式ORM默认无常用SQLAlchemy自带Django ORM迁移方便Admin后台需自己写或接第三方自带Admin改一改就能用适合场景小型服务、API、快速原型业务复杂、模块多、重后台的中型项目在开发效率上Django对这类带商品管理、订单管理、用户管理的项目非常友好。它自带的Admin界面可以直接拿来当运营后台用省掉一整套后台开发的工作量。Flask则胜在透明、可控适合那种你明确知道自己要什么、不想被框架约束的场景。2.2 我最终采用的组合方式那“flask-django”能不能共用我的实践是可以但要有边界。Django负责主站业务——商品、购物车、订单、用户、后台这是系统的核心Flask独立跑一个轻量服务负责辅助功能比如食材卡路里计算接口、BMR基础代谢率计算、推荐逻辑或者对接第三方营养数据源做爬虫清洗。为什么这么拆因为和营养相关的计算逻辑往往经常迭代今天用Mifflin-St Jeor公式算基础代谢明天可能换成Katch-McArdle公式后天可能想加一个AI估算热量工具。把这些易变的、独立的小模块抽出来放到Flask服务里不影响主站测试成本也低。两个服务通过HTTP接口通信Django这边用requests或httpx调用Flask的接口两边解耦得比较干净。如果你只想要一个方案我推荐主用Django。原因很直接购物网站最繁重的部分是后台管理、订单状态、数据关系这些Django都有成熟方案你不会把大量时间耗在重复造轮子上。2.3 开发环境的基础配置备忘不管选哪个框架开发环境里有几个容易踩坑的点需要提前确认Python版本建议3.10太老版本对Django新特性支持不好。虚拟环境一定要建venv或conda都行别把依赖装到全局。数据库默认用SQLite开发方便但如果你明确要上MySQL最好一开始就配好连接避免开发后期切换时被数据类型差异坑。环境变量尽量用.env文件管理数据库口令、密钥、支付接口Key都不要硬编码在源码里。Django建项目的基本操作也不复杂# 创建虚拟环境 python -m venv venv source venv/bin/activate # 安装Django pip install django # 创建项目和app django-admin startproject litefood_project cd litefood_project python manage.py startapp goods python manage.py startapp cart python manage.py startapp order python manage.py startapp user_profile3. 数据库设计从商品到订单的核心表结构3.1 领域模型建模的思路数据库设计是整个项目的地基。轻食品购物网站的核心实体包括用户、商品、商品分类、营养信息、购物车、订单、订单明细、健康档案。这里我重点讲两个容易被忽视的地方。第一个是商品和营养信息的关系。不建议把热量、蛋白质、脂肪、碳水直接塞进商品表。因为同一款商品可能有不同规格比如一盒鸡胸肉是100g装和200g装营养数据是“每100g”的标准值规划成单独的营养表会更清晰后期做营养筛查也更方便。第二个是用户健康档案和订单的关系。减脂人群有一个特殊需求记录每天的摄入量。这个可以通过“订单明细关联营养表”间接计算。用户在某个时间段内买了哪些商品每份热量是多少累加起来就是当天或近期的热量摄入估算。这种设计不需要额外做摄入记录模块就可以实现基本的热量追踪功能一举两得。3.2 核心表结构详解用Django ORM来描述这部分模型会清晰得多。下面给出核心模型示例# goods/models.py from django.db import models class Category(models.Model): name models.CharField(max_length64, uniqueTrue, verbose_name分类名称) parent models.ForeignKey(self, nullTrue, blankTrue, on_deletemodels.CASCADE, verbose_name父分类) class Meta: verbose_name 商品分类 verbose_name_plural verbose_name def __str__(self): return self.name class Product(models.Model): name models.CharField(max_length128, verbose_name商品名称) category models.ForeignKey(Category, on_deletemodels.PROTECT, related_nameproducts, verbose_name所属分类) price models.DecimalField(max_digits8, decimal_places2, verbose_name售价) stock models.PositiveIntegerField(default0, verbose_name库存) shelf_status models.BooleanField(defaultTrue, verbose_name上架状态) description models.TextField(blankTrue, verbose_name商品描述) image models.ImageField(upload_toproducts/%Y/%m/, blankTrue, verbose_name商品主图) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) class Meta: verbose_name 商品 verbose_name_plural verbose_name def __str__(self): return self.name class ProductNutrition(models.Model): product models.OneToOneField(Product, on_deletemodels.CASCADE, related_namenutrition, verbose_name关联商品) calories models.DecimalField(max_digits6, decimal_places1, verbose_name热量(kcal/100g)) protein models.DecimalField(max_digits5, decimal_places1, verbose_name蛋白质(g/100g)) fat models.DecimalField(max_digits5, decimal_places1, verbose_name脂肪(g/100g)) carbs models.DecimalField(max_digits5, decimal_places1, verbose_name碳水(g/100g)) fiber models.DecimalField(max_digits5, decimal_places1, default0, verbose_name膳食纤维(g/100g)) serving_size models.PositiveIntegerField(default100, verbose_name每份克重) class Meta: verbose_name 商品营养信息 verbose_name_plural verbose_name这里有个细节我用DecimalField而不是FloatField存价格和营养数据。电商项目最忌讳浮点数计算金额精度问题会直接在结算场景翻车。营养数据同样可能涉及热量累加用Decimal最稳。3.3 订单与购物车的状态设计购物车模型不复杂关键是在“用户维度”和“会话维度”之间做选择。登录用户可以绑User未登录用户可以用session标识。这里有个常见的坑用户登录前后购物车合并问题。简单做法是登录时把session购物车里的商品合并到用户购物车避免用户登录后购物车东西消失。订单表的状态字段建议用IntegerField加choices不要用字符串飘着# order/models.py class Order(models.Model): class StatusChoices(models.IntegerChoices): PENDING_PAYMENT 1, 待支付 PAID 2, 已支付 SHIPPING 3, 配送中 COMPLETED 4, 已完成 CANCELLED 5, 已取消 order_no models.CharField(max_length32, uniqueTrue, verbose_name订单号) user models.ForeignKey(auth.User, on_deletemodels.PROTECT, related_nameorders, verbose_name下单用户) status models.IntegerField(choicesStatusChoices.choices, defaultStatusChoices.PENDING_PAYMENT, verbose_name订单状态) total_amount models.DecimalField(max_digits10, decimal_places2, verbose_name订单总额) created_at models.DateTimeField(auto_now_addTrue, verbose_name下单时间) paid_at models.DateTimeField(nullTrue, blankTrue, verbose_name支付时间) class Meta: verbose_name 订单 verbose_name_plural verbose_name订单号不要用自增id裸奔一是容易被爬订单数据二是多表联查时不好看。我习惯用时间戳加随机串生成唯一订单号比如20250110153012XXXXXXXX这种格式保证唯一性和可读性。4. 核心功能实现商品、购物车与订单链路4.1 商品列表与筛选让减脂用户能挑东西商品列表页对普通电商只是“按分类拿数据”但对减脂食品来说还应该支持按营养指标筛选。比如用户想找“每100g热量低于150kcal、蛋白质高于20g”的鸡胸肉产品如果数据库层面不做支持前端就只能一次性拉到全部数据再过滤性能会越来越差。在后端实现搜索筛选时Django ORM的链式过滤就非常顺手# goods/views.py from django.db.models import Q def product_list(request): category_id request.GET.get(category) max_calories request.GET.get(max_calories) min_protein request.GET.get(min_protein) qs Product.objects.filter(shelf_statusTrue).select_related(nutrition) if category_id: qs qs.filter(category_idcategory_id) if max_calories: qs qs.filter(nutrition__calories__ltemax_calories) if min_protein: qs qs.filter(nutrition__protein__gtemin_protein) # 按相关度/销量/价格排序 sort request.GET.get(sort, created) sort_map { price_asc: price, price_desc: -price, calories_asc: nutrition__calories, sales: -sales_count, } if sort in sort_map: qs qs.order_by(sort_map[sort]) return render(request, goods/list.html, {products: qs})这里用到了select_related目的是一次SQL把关联的nutriton数据查出来避免模板里逐条商品再查一次营养表这在列表页尤其重要。4.2 购物车逻辑与库存扣减的坑购物车的核心操作是加购、改数量、删除、结算。表面上很简单实际最容易出问题的是“库存校验”和“并发扣减”。库存校验逻辑必须分两层。第一层在加购时校验第二层在提交订单时再次校验。因为从用户“加购物车”到“提交订单”之间可能相隔很久库存早就被其他人买光了。提交订单时发现库存不足应该提示用户哪些商品库存变动而不是整个订单提交失败。并发扣减库存如果只写朴素逻辑比如“先查库存、若大于0则扣减”在并发量上来时会超卖。Django下比较稳妥的方案是用select_for_update做行锁from django.db import transaction transaction.atomic def create_order_from_cart(user, cart_items): for item in cart_items: product Product.objects.select_for_update().get(iditem.product_id) if product.stock item.quantity: raise ValueError(f商品[{product.name}]库存不足) product.stock - item.quantity product.save() # 创建订单和订单明细...select_for_update会把涉及的商品行锁住直到事务结束。注意事务一定要用transaction.atomic包起来否则锁会在语句结束后立刻释放失去保护效果。4.3 订单提交与支付对接的注意事项支付环节对课程或演示项目来说通常不会真正接第三方支付网关但流程上要预留接口。我的建议是订单状态从“待支付”到“已支付”的变更动作抽成一个独立方法方便以后替换成真实支付回调。# order/services.py def mark_order_paid(order_no, paid_amountNone): order Order.objects.select_for_update().get(order_noorder_no) if order.status Order.StatusChoices.PENDING_PAYMENT: if paid_amount is not None and paid_amount ! order.total_amount: raise ValueError(支付金额与订单金额不一致) order.status Order.StatusChoices.PAID order.paid_at timezone.now() order.save(update_fields[status, paid_at, updated_at])还有一点容易被忽略用户连续点击“提交订单”按钮可能会生成多个重复订单。解决思路是前端按钮置灰加后端幂等校验。后端可以在订单创建接口上加入一个“防重令牌”用户点击时携带同一个令牌第一次请求成功后令牌失效第二次请求直接返回已有订单。5. 减脂场景的差异化功能卡路里计算与健康档案5.1 BMR和每日热量预算的计算逻辑减脂项目的核心差异化在于能帮用户算清楚一天到底该吃多少。这里用到的基础公式是Mifflin-St Jeor公式男性BMR 10 × 体重(kg) 6.25 × 身高(cm) - 5 × 年龄 5女性BMR 10 × 体重(kg) 6.25 × 身高(cm) - 5 × 年龄 - 161算出的BMR是基础代谢率再乘以活动系数得到TDEE每日总能量消耗。减脂用户要在这个基础上制造10%-20%的热量缺口得到每日推荐摄入热量。我单独写了一个Flask小服务来做这件事而不是堆在Django主项目里。接口设计得很简单# flask_calc/app.py from flask import Flask, request, jsonify app Flask(__name__) def calc_bmr(gender, weight_kg, height_cm, age): base 10 * weight_kg 6.25 * height_cm - 5 * age if gender male: return base 5 return base - 161 app.route(/api/calorie/budget, methods[POST]) def calorie_budget(): data request.get_json() gender data.get(gender) weight float(data.get(weight)) height float(data.get(height)) age int(data.get(age)) activity data.get(activity, moderate) deficit_ratio float(data.get(deficit_ratio, 0.15)) bmr calc_bmr(gender, weight, height, age) activity_factors { sedentary: 1.2, light: 1.375, moderate: 1.55, active: 1.725, } tdee bmr * activity_factors.get(activity, 1.55) recommend_calories tdee * (1 - deficit_ratio) return jsonify({bmr: round(bmr), tdee: round(tdee), recommend_calories: round(recommend_calories)}) if __name__ __main__: app.run(port5001)Django这边只需要在用户填写健康档案时调用这个接口拿推荐值然后存下来。用户逛商品页时每个商品的卡路里一目了然甚至能显示“相当于今日热量的百分之几”。5.2 健康档案与推荐逻辑健康档案表可以设计成一人一条活跃档案# user_profile/models.py class HealthProfile(models.Model): user models.OneToOneField(auth.User, on_deletemodels.CASCADE, related_nameprofile) gender models.CharField(max_length8, choices[(male,男),(female,女)]) height_cm models.DecimalField(max_digits5, decimal_places1) weight_kg models.DecimalField(max_digits5, decimal_places1) birth_date models.DateField(nullTrue, blankTrue) activity_level models.CharField(max_length16, defaultmoderate) daily_calorie_target models.PositiveIntegerField(nullTrue, blankTrue) updated_at models.DateTimeField(auto_nowTrue)有了这个表不只是能算预算还可以做“今日已购热量”统计。用户在订单列表里看今天买了什么后端把订单明细里每件商品的营养数据拿出来按购买数量乘一遍汇总成“今日热量/蛋白质/碳水/脂肪摄入”。这个功能在普通电商项目里没有但在减脂场景里非常亮眼也是答辩或展示时最能讲出故事的功能点。6. 实战复盘开发过程中最容易翻车的几个位置6.1 图片上传与静态文件的配置商品必须带图没图的轻食品商城完全不像话。Django的图片处理配置虽然简单但每个人第一次都容易踩坑。核心配置就三块# settings.py MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static]开发模式下要在主路由里加上media的服务from django.conf import settings from django.conf.urls.static import static urlpatterns [...] if settings.DEBUG: urlpatterns static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)另外表单要支持上传图片必须加上enctypemultipart/form-data这个很多人会忘。Python的Pillow库别忘了装否则ImageField会报错。6.2 混合架构下的会话问题如果你像我一样把营养计算交给Flask辅助服务要特别注意两个服务之间的会话隔离问题。Django的session存在数据库或Redis里Flask默认的session是签名的cookie。用户在主站登录后调Flask接口时Flask是不认识用户身份的。我的解决办法Flask服务只做“无状态计算”不在Flask层维护登录态。身份认证留在Django需要调用Flask时通过内部服务把必要参数传过去即可比如把身高体重年龄性别传到Flask接口。这样两边各自职责清楚不会打架。如果你有更复杂的需求比如Flask服务也需要鉴权可以用一个共享的API Token做服务间认证而用户的登录态始终只在主站维护。6.3 部署环节的常见问题项目开发完部署到Linux服务器上时最容易出问题的有四个地方静态文件没有用collectstatic收集页面全裸奔。数据库从SQLite切换到MySQL时字段类型不兼容。DEBUG False之后静态文件和media文件不显示了。gunicorn配置的worker数不合理内存直接被打满。部署用的gunicorn命令我的习惯配置是gunicorn litefood_project.wsgi:application \ --bind 0.0.0.0:8000 \ --workers 3 \ --timeout 60worker数一般按CPU核数×21估算。如果服务器内存不大千万别盲目multi-workerDjango的ORM和图片处理都挺吃内存的。前端再用Nginx做反向代理静态文件直接交给Nginx处理Django只处理动态请求整体压力会小很多。7. 让项目不止于作业异步任务与后续扩展思路7.1 什么时候需要引入异步任务购物网站里有几个场景天然适合异步化订单提交后发送通知、支付回调后同步订单状态、商品导入时处理图片、用户下单后记录行为日志。这些任务如果同步执行会造成不必要的接口耗时。Django生态可以直接用Celery加Redis实现异步任务。拿“下单成功发送通知”来说可以把通知任务丢到队列里接口立即返回Celery worker在后台慢慢处理。# order/tasks.py from celery import shared_task shared_task def send_order_notification(order_id): order Order.objects.select_related(user).get(idorder_id) # 假设接邮件、短信或站内信服务 message f您的订单{order.order_no}已生成请尽快完成支付。 notify_service.send(order.user.phone, message)7.2 数据统计与运营面板做完了基础交易链路之后可以再往前一步给运营加一个简单的数据看板统计每天的销售额、订单量、热销商品Top10、各分类占比。这些统计可以用Django的聚合查询直接实现比如from django.db.models import Sum, Count daily_stats ( Order.objects.filter(status__in[Order.StatusChoices.PAID, Order.StatusChoices.COMPLETED]) .values(created_at__date) .annotate(total_salesSum(total_amount), total_ordersCount(id)) .order_by(-created_at__date) )这个看板对后台运营意义很大也是向“真实可用系统”靠拢的好抓手。配合Django Admin做定制可以做到不看代码也能管商品、管订单、看统计项目完整度会明显提高。7.3 扩展方向推荐与营养追踪减脂食品购物网站再往后做有两个我很看好的方向。一个是智能推荐根据用户健康档案里的热量预算和口味偏好推荐合适的食材和套餐组合推荐逻辑可以放到Flask辅助服务里持续迭代。另一个是周期化营养追踪让用户按周查看热量摄入曲线、蛋白质是否达标再结合体重变化数据生成阶段报告。这两个方向都在“健康管理”这条线上持续加码购物本身会变成入口而非终点。对个人项目来说也是持续迭代空间最大的部分。最后分享一点个人体会做这类项目最怕一上来就埋头写CRUD写完才发现和普通电商没有任何区别。先把“减脂用户到底在乎什么”想透再倒推界面和接口设计项目做出来才会有灵魂。遇到拿不准的技术选型先动手做一个最小原型验证别在文档里纠结太久。先把主链路跑通再一步步迭代细节这才是做这类系统最务实的节奏。
