1. 为什么选校园外卖这个场景练手
直接说结论：校园外卖点餐系统是我接触过的、最适合用来把 Django 从"会写 Demo"推向"能做项目"的业务场景之一。原因很简单——它麻雀虽小，但五脏俱全。用户端要注册登录、浏览菜品、加购物车、下单支付；商家端要管理菜品、处理订单；系统层面要处理订单状态流转、库存扣减、并发防超卖这些问题。一套做下来，CRUD、ORM 关联查询、事务、缓存、权限控制，Django 的核心知识点基本全过了一遍。
更重要的是，这个业务的逻辑足够直观。你不需要先去理解复杂的领域概念，点餐这件事所有人都经历过：用户点什么、商家出什么餐、谁来配送、状态怎么变。带着这种天然的直觉去做系统设计，会比做一个抽象的"电商系统"顺畅得多。我在带新手做课程设计或者毕业设计时，也经常推荐这个方向——不是因为它简单，而是因为它能在有限的时间内让你完整地经历一个项目从设计到落地的全过程。
当时做这个系统时我给自己定的目标是：不用现成的后台管理框架，核心业务逻辑必须自己手写。用 Django 自带的 Admin 确实能快速搭出一个后台，但如果只在 Admin 里点来点去，做完之后你对系统的理解会非常浅。只有自己写视图、自己处理表单校验、自己控制事务，你才能真正理解一个 Web 系统是如何运作的。
2. 技术选型：Django 在这个项目里到底合适在哪
2.1 Django 的核心优势与代价
选 Django 不是因为它最流行，而是因为它在这个场景下的几个特性正好打在需求点上：
- 自带 ORM，模型的关联查询写起来非常顺手。订单、订单项、菜品、商家这几张表之间的关联关系，如果用原生 SQL 去维护，工作量会大很多。
- 自带 Admin，虽然我前面说不要依赖它，但开发阶段用来快速查看数据、验证业务逻辑，效率非常高。
- 模板系统能直接渲染服务端页面，对于这种以表单提交为主的系统，不需要前后端分离也能做出完整流畅的交互。
- 中间件、信号、事务钩子这些机制，让一些横切逻辑（比如登录校验、订单状态变更后的日志记录）有了规范的落点。
当然也有代价。最明显的是 Django 的"重量感"——启动一个项目有大量的默认配置，新手经常会困惑"这个文件是干什么的""为什么要配这个"。我的建议是：第一遍照默认走，不要一上来就动结构；等跑通了再说。你真正需要手动配置的东西，其实就那么几处：数据库连接、静态文件路径、INSTALLED_APPS注册、路由分发规则。
2.2 运行环境与 Python 版本选择
我用的组合是 Python 3.10 + Django 4.2 LTS。为什么不用最新的 Django 5.x？做项目讲究稳。4.2 是 LTS 版本，主流教程和第三方库的兼容性都是围绕 LTS 来做的，遇到问题搜资料方便，不会卡在版本兼容上。Python 3.10 以上对 Django 4.2 的支持非常成熟，够用。
数据库方面，开发环境直接用 SQLite 就够了，零配置，跑起来就走。但如果你想体现项目的完整度，建议从一开始就配 MySQL（5.7 或 8.0），Django 的 ORM 会帮你把差异抹平，但你在配置连接、处理字符集、排查事务问题时会积累很多实战经验。比如 MySQL 的utf8mb4字符集、事务隔离级别、连接池配置，这些在 SQLite 上是遇不到的坑，而它们恰恰是面试和工作里经常被问到的点。
2.3 项目结构怎么组织比较顺手
我不建议把业务逻辑全部堆在views.py里。Django 官方文档虽然没强制，但稍微大一点的项目这样写就是灾难。我习惯的目录结构是这样的：
campus_order/ ├── manage.py ├── config/ # 项目根配置 │ ├── settings.py # 配置文件，按环境拆分 │ ├── urls.py # 总路由入口 │ └── wsgi.py ├── apps/ │ ├── users/ # 用户模块：注册、登录、地址管理 │ ├── merchants/ # 商家模块：菜品管理、营业状态 │ ├── orders/ # 订单模块：下单、支付、状态流转 │ └── common/ # 公共工具：分页、响应封装、异常处理 └── static/ # 静态资源把业务按 app 拆分，每个 app 只负责自己那一摊事，模块之间通过接口通信，后期加功能时不需要到处改。比如后来我想加一个"商家销量排行"，只需要在orders里加一个聚合查询，完全不影响其他模块。
3. 数据库设计：几张核心表的建模思路
3.1 实体关系梳理
校园外卖系统的核心实体有：用户、商家、菜品、订单、订单项、购物车、地址。它们之间的关系是：
- 用户和订单：一对多，一个用户有多个订单，订单归属用户。
- 商家和菜品：一对多，一个商家有多个菜品。
- 订单和订单项：一对多，一个订单包含多个菜品快照。
- 订单和地址：多对一，每个订单对应一个收货地址。
这里有一个非常关键的设计决定：订单项里存的是菜品的快照信息，而不是通过外键去关联菜品表。为什么要这样？因为菜品价格是会变的。用户下单之后，商家可能第二天就改了价格。如果订单项只存一个外键，你去查历史订单时看到的价格可能是改过的，这会产生对账纠纷。正确的做法是，在下单的那一刻，把菜品名称、价格、图片这些关键信息复制一份到订单项里，让订单变成一条独立的历史记录。
3.2 核心数据表字段设计
订单表是所有表里最重要的，我贴一下我实际用的结构：
class Order(models.Model): STATUS_CHOICES = ( ('pending', '待支付'), ('paid', '待接单'), ('accepted', '已接单'), ('delivering', '配送中'), ('completed', '已完成'), ('cancelled', '已取消'), ) order_no = models.CharField(max_length=32, unique=True, verbose_name='订单编号') user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='orders') merchant = models.ForeignKey(Merchant, on_delete=models.CASCADE, related_name='orders') address = models.CharField(max_length=255, verbose_name='收货地址') contact_name = models.CharField(max_length=32, verbose_name='联系人') contact_phone = models.CharField(max_length=16, verbose_name='联系电话') total_amount = models.DecimalField(max_digits=8, decimal_places=2, verbose_name='订单总金额') status = models.CharField(max_length=16, choices=STATUS_CHOICES, default='pending') remark = models.CharField(max_length=255, blank=True, verbose_name='备注') created_at = models.DateTimeField(auto_now_add=True) paid_at = models.DateTimeField(null=True, blank=True) completed_at = models.DateTimeField(null=True, blank=True)有几个设计细节值得说明：
order_no用唯一字段，不用自增 ID 给用户看。自增 ID 会暴露订单量，而且不方便做分布式扩展。我生成订单号的规则是时间戳加随机数，再加一点用户 ID 的混淆，保证唯一。total_amount用DecimalField，绝对不用FloatField。浮点数的精度问题在金额上会出大事故。- 状态流转时间单独记录，比如
paid_at、completed_at，方便后面做数据统计和超时处理。
3.3 购物车表：冗余还是不冗余
购物车的设计有两种方案：一种是独立表，存用户、菜品、数量；另一种是存在 Session 里，不落库。校园外卖系统我建议落库，因为用户可能会换设备登录，购物车如果只存在 Session 里，换台电脑就丢了，体验很差。
购物车表不需要存价格快照，因为它只是一个"暂存草稿"，真正下单时读取最新价格。结构很简单：
class CartItem(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) dish = models.ForeignKey(Dish, on_delete=models.CASCADE) quantity = models.PositiveIntegerField(default=1) created_at = models.DateTimeField(auto_now_add=True) class Meta: unique_together = ('user', 'dish')用unique_together保证同一用户同一菜品只有一条记录，数量累加或修改，不会产生重复行。
3.4 索引设计：别小看这几行
我在订单表上加了两个索引：(user, status)和created_at。前者支撑用户查看"我的订单"并按状态筛选，后者支撑商家端按时间倒序拉新订单。没有索引的前提下，数据量上去后这两类查询会非常难受。Django 里用 ORM 的Meta.indexes来定义，启动时自动建索引，非常省事。
另外提醒一个容易忽略的点：外键字段虽然在 Django 里会自动建索引，但如果你在多个外键上做联合查询，需要考虑是否要建联合索引。比如"某个用户在某段时间内的订单"，(user, created_at)联合索引可以避免回表查询。
4. 核心业务逻辑的实现细节
4.1 用户端的下单流程
下单是整个系统最核心的路径，我拆成了几步：校验购物车 → 生成订单 → 扣减库存 → 清空购物车。最关键的是第二步和第三步必须放在同一个数据库事务里，否则会出现"订单生成了但库存没扣"或者反过来"库存扣了但订单失败"的脏数据。
Django 里用transaction.atomic()包起来：
from django.db import transaction @transaction.atomic def create_order(request): user = request.user cart_items = CartItem.objects.select_related('dish').filter(user=user) if not cart_items: raise ValueError('购物车为空') total_amount = sum(item.dish.price * item.quantity for item in cart_items) order = Order.objects.create( order_no=generate_order_no(user.id), user=user, merchant=cart_items[0].dish.merchant, address=request.POST['address'], contact_name=request.POST['contact_name'], contact_phone=request.POST['contact_phone'], total_amount=total_amount, ) for item in cart_items: OrderItem.objects.create( order=order, dish_name=item.dish.name, dish_price=item.dish.price, quantity=item.quantity, image=item.dish.image, ) # 扣减库存 Dish.objects.filter(id=item.dish.id, stock__gte=item.quantity).update( stock=F('stock') - item.quantity ) cart_items.delete() return order这里有一个细节：扣库存用的是F('stock') - item.quantity配合filter(stock__gte=item.quantity)，而不是先SELECT出来在 Python 里判断再UPDATE。前者是原子操作，后者在高并发下会超卖。
4.2 商家端的订单状态流转
商家的核心操作是接单和发货。这两个动作都对应一个状态变更。我在设计时把状态流转做了集中控制，而不是散落在各个视图里：
ORDER_STATUS_TRANSITIONS = { 'paid': ['accepted', 'cancelled'], # 待接单可以改成已接单，也可以取消 'accepted': ['delivering', 'cancelled'], # 已接单可以发货，也可以取消 'delivering': ['completed'], }每次状态变更前先校验当前状态是否允许这种流转，不允许就抛异常。这样避免了用户端和商家端同时操作导致的状态错乱。比如用户在"待接单"时申请退款，商家同时点了"接单"，如果没有这层校验，两个请求可能会产生不合理的最终状态。
4.3 支付模块怎么处理
正经的校园外卖项目需要对接微信支付或支付宝，但对接真实支付需要商户号和资质，个人项目通常没有。我当时用了模拟支付的方式：用户点击"确认支付"，系统生成一条支付记录，模拟第三方回调，然后把订单状态改成"已支付"。
即使只是模拟，也要走完整的流程：创建支付单 → 用户确认 → 支付回调 → 校验金额 → 更新订单。这样设计的意义在于，以后真的接入第三方支付时，只需要替换"假回调"这部分代码，前后端的交互逻辑完全不用动。
4.4 权限控制：Django 的权限系统怎么用
用户端和商家端是两种完全不同的角色，权限必须分开控制。Django 自带auth应用有 Group 和 Permission，但在这个场景下用起来有些重。我的做法是：在用户表上加一个role字段（user / merchant），再自定义一个装饰器做视图级权限控制：
from functools import wraps from django.http import JsonResponse def merchant_required(view_func): @wraps(view_func) def wrapper(request, *args, **kwargs): if not request.user.is_authenticated: return JsonResponse({'code': 401, 'msg': '未登录'}) if getattr(request.user, 'role', '') != 'merchant': return JsonResponse({'code': 403, 'msg': '无权限'}) return view_func(request, *args, **kwargs) return wrapper这样在商家端的视图函数上直接@merchant_required注解即可，非常清晰。Django 自带的login_required处理登录校验，自己的注解处理角色校验，各司其职。
5. 从开发到部署：可能踩的坑和我的解决思路
5.1 事务里的 SELECT 不能防超卖
前面提到用F()表达式和条件更新来扣库存，这是正确做法。但很多人第一次写的时候会写成：
dish = Dish.objects.get(id=dish_id) if dish.stock >= quantity: dish.stock -= quantity dish.save()这段代码在并发情况下会出问题。两个请求同时读到stock=5，都判断可以扣，都执行save()，最后库存变成 3，但实际卖了 4 份。这是因为save()是"读出再写回"的模式，不是原子的。用F()表达式配合filter(stock__gte=quantity)做UPDATE，SQL 层面就保证了原子性。
5.2 设置里别忘了时区
Django 默认的TIME_ZONE是UTC，如果你不改成Asia/Shanghai，created_at这些字段存的时间会和你本地时间差 8 个小时。第一次做项目的人基本都会踩这个坑，等你发现"我的订单时间怎么不对"时，数据已经写了一堆了。
我做这两个配置：
TIME_ZONE = 'Asia/Shanghai' USE_TZ = FalseUSE_TZ = False是让数据库里直接存本地时间，不做时区转换。对于纯国内的项目，这个配置最省心。如果你的系统有海外用户，那就另说。
5.3 上传图片的路径配置
菜品图片是外卖系统的刚需。Django 处理文件上传很简单，但要提前把MEDIA_URL和MEDIA_ROOT配置好：
MEDIA_URL = '/media/' MEDIA_ROOT = BASE_DIR / 'media'同时在根路由里加上静态服务：
from django.conf import settings from django.conf.urls.static import static urlpatterns = [...] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)这一步只影响开发环境，真正部署时由 Nginx 来处理媒体文件。但如果你开发阶段没配好，预览菜品图片时会一直 404，非常影响体验。
5.4 部署时的经典坑：ALLOWED_HOSTS 和静态文件收集
把项目部署到服务器上时，最常见的报错是DisallowedHost，这是因为ALLOWED_HOSTS没有配置。默认是空的，线上必须加上你的域名或 IP：
ALLOWED_HOSTS = ['your-domain.com', 'your-server-ip']然后 Django 的静态文件在 Debug 模式下由开发服务器托管，关掉 Debug 后必须执行python manage.py collectstatic，把静态文件收集到一个目录下交给 Nginx。这个流程如果没走，页面会变得非常难看——所有 CSS、JS 全部 404。
我之前在部署时用的是 Gunicorn + Nginx 的组合。Gunicorn 负责跑 Django，Nginx 负责反向代理和静态文件服务。对于校园外卖这种并发量不大的系统，这个组合稳定且配置简单。
5.5 文档和数据库文件：项目的最后一块拼图
这个系统主要包含源码、数据库文件和项目文档三部分。源码自然是核心，数据库文件我导出了一份初始化数据——内置了测试账号、几个示例商家、菜品和演示订单，这样别人拿到项目后不用从零开始注册商家、录菜品，直接就能看到效果。项目文档我写的是系统设计说明书，包含 ER 图、功能清单、接口说明和部署步骤。这个习惯我一直保持：项目能跑只是第一步，能让人快速跑起来、看懂设计思路，才是完整的交付。
6. 我还做了哪些增强功能
基础功能做完之后，我陆续加了一些增强功能，这些功能让项目从"课设水平"往"实际可用"靠拢：
- 菜品搜索和分类筛选。按分类（川菜、快餐、饮品等）筛选菜品，按名称或描述做模糊搜索。
- 用户历史订单一键复购。从历史订单的订单项里读取当前在售的菜品，重新加进购物车。注意只加"当前还在售"的菜，下架菜品自动跳过。
- 商家端销量统计。用 Django ORM 的聚合查询，统计每个菜品的销量和营业额，按日、周、月维度。
- 配送时间预估。根据商家的平均接单时间和配送距离做一个简单的预估展示，因为校园范围小，用固定模板计算就够了。
这些功能并没有增加太多代码量，但对系统的完整度提升非常明显。尤其是复购功能，实际点餐场景里用得非常频繁，做出来之后整个系统就有了"顺手"的感觉。
7. 经验总结：做完这个项目我最大的收获
整个项目做下来，我最大的感受是：写代码只占了一半的工作量，设计决策和踩坑调试占了另外一半。数据库表结构怎么设计、订单状态怎么流转、并发情况下怎么保证数据一致性，这些问题想清楚了，代码写起来就是"翻译思路"而已。
给准备做类似项目的人几个建议：
- 先把业务流程图和状态机图画出来再动手写代码。订单状态流转、用户操作流程、商家操作流程，这三张图画清楚，开发效率至少高一倍。
- 不要过度设计。第一版能把核心流程跑通就够了，把下单选型、权限控制、库存扣减这几个核心场景做扎实，比堆功能有价值得多。
- 数据设计时多想一步：这个字段以后要用来做什么统计？这个表需不需要冗余快照字段？多花五分钟想清楚，后面省的不止五十分钟。
- 项目完成后一定要写文档。写好部署文档和系统设计说明，既方便别人使用你的项目，也能帮你自己复盘整个系统的设计逻辑。
做完这个校园外卖点餐系统之后，我对 Django 的掌握程度有了质的提升——不仅仅是会用框架，而是知道在真实业务场景里怎么运用它做出合理的设计决策。这个项目的源码和数据库文件我都整理好了，有需要拿来参考或者学习的朋友，直接拿去用，有问题欢迎交流。
