最近在帮一个做社区团购的朋友整理他们的线上销售流程，顺手把之前带学生做的那套“基于Django的智能水果商城销售系统”重新翻出来打磨了一遍。这个项目说是毕业设计选题，但拆开看其实就是一套标准的小型生鲜电商系统，只不过业务场景落在了“水果”这类短保商品上：保质期短、损耗高、价格波动快，这些特点决定了它比普通服装、数码商城更依赖库存预警和销售数据分析。如果你正在做同类课题，或者刚学完Django想找一个能写进简历的完整项目练习，这套系统的设计和实现过程应该能给你不少能直接抄作业的东西。
这整套东西的核心价值在于：用Django把用户端、商家端、数据报表三块业务完整串了起来。用户端做注册登录、商品浏览、购物车、下单支付；商家端做商品上下架、库存管理、订单处理；再加上一张基于销售数据的采购建议报表，就是标题里“智能”二字的落点。整体下来大概两三千行代码，配合MySQL和Bootstrap，从数据库建模到部署上线，覆盖了Django开发的主流环节，非常适合作为课程设计、毕业设计，或者作为你第一次独立完成全栈项目的练手题材。
1. 项目定位与整体思路拆解
1.1 这套系统到底解决水果生意的什么痛点
水果和标准工业品最大的区别在于“保鲜期”和“损耗率”。一件衣服放三个月不影响销售，一串葡萄放三天可能就只能打折处理。所以水果商城的业务逻辑里，库存周转和临期处理这两个问题比普通商城要尖锐得多。商家不能只关心“卖出去了多少”，还得盯住“还有多少库存”“哪些水果已经在货架上躺了很久”“明天该进多少货”。
我做这套系统时，围绕水果经营的这几个特点重新梳理了业务需求：
- 商品信息管理：水果的品种、产地、规格（按斤还是按箱）、单位价格、保质期、库存量。
- 库存与预警：当某种水果库存低于设定的阈值时，系统要能自动标记为“低库存”，提醒商家补货。
- 订单快速处理：生鲜订单时效性高，商家需要在后台快速看到待发货订单，尽快处理。
- 销售数据统计：按月、按品类统计销量和销售额，帮助商家判断哪些水果走量大、哪些品类该做活动。
这些需求单独看都不复杂，但要在一套系统里完整落地，并且让商家和用户两边都用得顺手，就涉及到角色划分、权限控制、数据表设计和业务状态流转等一系列工程问题。
1.2 技术选型：为什么非Django不可
这个项目选Django，坦白说不是因为它是最新最酷的框架，而是因为它本身“电池齐全”的特性最适合这种多角色、多模块的业务系统。
首先，Django自带的Admin后台能极大降低开发成本。在项目初期，商品分类、用户管理等基础数据维护直接靠Admin就能顶上，后面再逐步替换成定制页面。这意味着你不需要从零写一套后台管理界面，可以把精力优先放在用户端和商家端的核心流程上。
其次，Django的ORM对这类业务系统实在太友好了。水果商城里最频繁的操作就是“查商品”“减库存”“生成订单”，这些抽象成数据库操作后都是典型的关联查询和事务处理。Django ORM用Python代码表达这些操作，比手写SQL更直观，而且自带防止SQL注入的参数化查询机制。
第三，Django的认证和权限体系是现成的。用户注册、登录、会话管理、权限校验，这些电商系统的地基功能，Django都已经帮你封装好了。我们要做的只是在此基础上扩展一个“商家”角色，而不是从零设计一套session和cookie机制。
相比之下，如果选Flask，轻量是轻量，但用户认证、Admin、ORM、表单这些都要自己组装，工作量会上来不少；Spring Boot在Java生态里确实强大，但对大多数做毕设或者转型Python的同学来说，学习曲线偏陡，写起来也啰嗦。Django在“开箱即用”和“可控性”之间找到了一个很适合中小型项目的平衡点。
1.3 角色权限与功能模块划分
这套系统设计了三种角色：普通用户（买家）、商家（卖家）、系统管理员（超级用户）。三种角色在同一个平台上操作，但看到的页面和能做的事完全不同。
| 角色 | 核心权限 | 主要功能 |
|---|---|---|
| 普通用户 | 浏览、购买 | 注册登录、商品搜索与筛选、购物车、下单、查看个人订单 |
| 商家 | 商品与订单管理 | 商品上下架、库存预警查看、订单发货与退款处理、销售报表 |
| 管理员（超级用户） | 平台管控 | 用户管理、商家审核、数据总览、后台维护 |
功能模块划分上，我拆成了四个子应用（app），每个应用职责单一，避免代码揉成一团：
- users：用户注册、登录、商家账号绑定。
- goods：商品分类、商品信息、库存管理、搜索排序。
- orders：购物车、订单生成、支付回调、订单状态流转。
- reports：销售统计、库存预警、采购建议。
这样划分的好处是，每个app只关心自己领域内的模型和视图，后期扩展功能（比如加一个“优惠券”模块）不会牵一发而动全身。这也是Django项目从“能跑”走向“好维护”的关键一步。
2. 环境准备与数据库建模实战
2.1 从零搭建Django项目和子应用
我用的环境是Python 3.10 + Django 4.2 LTS版本。之所以不追最新版，是因为LTS版本有长期维护保障，生产环境踩坑少，网上的解决方案也最全。如果只是做毕设，用Django 5.x也没有问题，核心API差异不大。
初始化项目的过程很简单：
# 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows下是 venv\Scripts\activate # 安装Django和数据库驱动 pip install django==4.2 mysqlclient # 创建项目和子应用 django-admin startproject fruit_mall cd fruit_mall python manage.py startapp users python manage.py startapp goods python manage.py startapp orders python manage.py startapp reports创建完成后，记得在settings.py里把四个app注册进INSTALLED_APPS，然后配置数据库连接：
DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'fruit_mall', 'USER': 'root', 'PASSWORD': 'your_password', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', }, } }这里有个实际经验：很多同学在Windows上装mysqlclient会卡住，报Microsoft Visual C++ 14.0 is required。如果遇到，可以先pip install pymysql，然后在fruit_mall/__init__.py里加一句：
import pymysql pymysql.install_as_MySQLdb()这个兼容方案在开发环境实测很稳，能省下装Visual C++ Build Tools的时间。
2.2 五大核心表设计：用户、商品、订单、购物车、库存
数据库建模是整个项目的地基，表结构设计合理了，后面写业务逻辑会顺很多。我一共设计了六张核心模型表，分别放在对应的app里。
用户模型继承Django自带的AbstractUser，在此基础上扩展字段：
from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): phone = models.CharField(max_length=11, blank=True, verbose_name='手机号') address = models.CharField(max_length=255, blank=True, verbose_name='收货地址') is_merchant = models.BooleanField(default=False, verbose_name='是否为商家')关键点是加了一个is_merchant布尔字段，用来区分普通用户和商家账号。商家除了能购物，还能进入商家管理后台。这种设计比单独建一张“商家表”再和用户做OneToOne关联要简单一些，判断登录用户是否有商家权限时只需要检查一个字段。
商品模型放在goods应用里：
class Category(models.Model): name = models.CharField(max_length=50, verbose_name='分类名称') parent = models.ForeignKey('self', null=True, blank=True, on_delete=models.CASCADE, verbose_name='父分类') class Goods(models.Model): category = models.ForeignKey(Category, on_delete=models.CASCADE, related_name='goods', verbose_name='商品分类') name = models.CharField(max_length=100, verbose_name='商品名称') origin = models.CharField(max_length=100, blank=True, verbose_name='产地') price = models.DecimalField(max_digits=8, decimal_places=2, verbose_name='销售单价') unit = models.CharField(max_length=10, default='斤', verbose_name='计价单位') stock = models.PositiveIntegerField(default=0, verbose_name='库存数量') safety_stock = models.PositiveIntegerField(default=10, verbose_name='库存预警阈值') sales_count = models.PositiveIntegerField(default=0, verbose_name='累计销量') cover_image = models.ImageField(upload_to='goods/', blank=True, verbose_name='商品图片') status = models.CharField(max_length=10, default='on', choices=(('on', '上架'), ('off', '下架')), verbose_name='商品状态') created_at = models.DateTimeField(auto_now_add=True, verbose_name='创建时间')这里有两个字段值得展开说。safety_stock是库存预警阈值，商家可以针对不同水果单独设置。苹果可以放得久，阈值设低点；草莓容易坏、卖得快，阈值就得调高。这个字段直接支撑了后面“智能库存预警”的功能。
goods的ForeignKey里指定了related_name='goods'，这意味着从Category反查商品时可以写category.goods.all()，比默认的category.goods_set.all()读起来语义更清晰。
订单模型放在orders应用，分订单主表和订单明细表两张：
class Order(models.Model): order_no = models.CharField(max_length=32, unique=True, verbose_name='订单编号') user = models.ForeignKey(User, on_delete=models.PROTECT, related_name='orders', verbose_name='下单用户') total_amount = models.DecimalField(max_digits=10, decimal_places=2, verbose_name='订单总金额') pay_status = models.CharField(max_length=10, default='unpaid', choices=( ('unpaid', '待支付'), ('paid', '已支付'), ('refunding', '退款中'), ('refunded', '已退款'), ), verbose_name='支付状态') order_status = models.CharField(max_length=10, default='pending', choices=( ('pending', '待发货'), ('shipped', '已发货'), ('completed', '已完成'), ('cancelled', '已取消'), ), verbose_name='订单状态') receiver = models.CharField(max_length=50, verbose_name='收货人') receiver_phone = models.CharField(max_length=11, verbose_name='收货电话') receiver_address = models.CharField(max_length=255, verbose_name='收货地址') remark = models.CharField(max_length=255, blank=True, verbose_name='订单备注') created_at = models.DateTimeField(auto_now_add=True, verbose_name='下单时间') paid_at = models.DateTimeField(null=True, blank=True, verbose_name='支付时间') class OrderItem(models.Model): order = models.ForeignKey(Order, on_delete=models.CASCADE, related_name='items', verbose_name='所属订单') goods = models.ForeignKey(Goods, on_delete=models.PROTECT, verbose_name='商品') goods_name = models.CharField(max_length=100, verbose_name='商品快照名称') goods_price = models.DecimalField(max_digits=8, decimal_places=2, verbose_name='商品快照价格') quantity = models.PositiveIntegerField(default=1, verbose_name='购买数量') subtotal = models.DecimalField(max_digits=10, decimal_places=2, verbose_name='小计金额')订单表这里有两个设计细节要划重点。第一，on_delete=models.PROTECT而不是CASCADE，目的是不让用户被删连带把订单也删掉——订单是交易记录，必须永久保存。第二，OrderItem里保存了goods_name和goods_price这两个“快照”字段。商品表里的名称和价格随时可能被商家修改，但订单明细必须保留用户下单那一刻的信息，否则将来对账时会出现“订单金额和商品当前价格对不上”的纠纷。
购物车模型：
class CartItem(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='cart_items', verbose_name='用户') goods = models.ForeignKey(Goods, on_delete=models.CASCADE, verbose_name='商品') quantity = models.PositiveIntegerField(default=1, verbose_name='数量') created_at = models.DateTimeField(auto_now_add=True, verbose_name='加入时间') class Meta: unique_together = ('user', 'goods')unique_together保证同一用户对同一商品只有一条购物车记录，重复加购时做数量累加而不是插新行。这样购物车页面渲染、数量修改时都省事。
2.3 ORM删除与关联查询的实战细节
Django ORM在项目里最常用的操作除了查询，就是删除对象。热词里提到“django执行查询-删除对象”，这个操作在水果商城里有大量的实际场景。
删除对象最基础的方式是：
# 删除单条记录 goods = Goods.objects.get(pk=1) goods.delete()但在真实业务里，删除操作必须考虑外键关联。比如删除一个商品分类时，分类下可能还有商品。我在Category模型里设置的on_delete=models.CASCADE，意思是删分类时连分类下的商品一起删。这在水果商城里就需要慎重——如果一个分类下有历史订单关联的商品，商品被连带删除后，OrderItem里的商品外键就会出问题。
所以我的实际处理是：对OrderItem的goods字段用PROTECT，对Goods的category字段用PROTECT。这样一来，只要分类下还有商品，系统就会阻止你删除分类；只要商品还有订单引用，系统就会阻止你删除商品。宁可让商家的删除操作报错，也不能破坏交易记录的完整性。
如果要实现“软删除”，更稳妥的方案是给模型加一个is_active字段：
is_active = models.BooleanField(default=True, verbose_name='是否有效')下架商界的商品时只需要把is_active设为False，而不是真的从数据库里删掉。业务查询默认加一层filter(is_active=True)，既保留了数据，又实现了“删除”的效果。这在电商项目里是常见做法，比物理删除安全得多。
关联查询方面，热门搜索里的“django添加好友”其实是ManyToManyField的使用场景，水果商城没有好友关系，但购物车和商品、订单和商品之间存在类似的关联操作。重点是用好select_related和prefetch_related来避免N+1查询。我第一次写订单列表页时直接Order.objects.all()然后循环取order.items.all()，结果页面加载慢得像蜗牛。加一句prefetch_related('items__goods')之后，查询次数从“1+N”变成了两条SQL，速度立竿见影。
3. 商家端功能实现：从登录到库存预警
3.1 商家登录与会话权限控制
普通用户登录用的是Django自带的authenticate和login，商家登录本质上也一样，只是多了is_merchant校验。我在users应用里写了一个merchant_required装饰器，用来保护所有商家后台视图：
from functools import wraps from django.shortcuts import redirect def merchant_required(view_func): @wraps(view_func) def wrapper(request, *args, **kwargs): if not request.user.is_authenticated: return redirect('users:login') if not request.user.is_merchant: return redirect('goods:index') return view_func(request, *args, **kwargs) return wrapper使用方式很直接：
@merchant_required def merchant_dashboard(request): # 商家后台首页逻辑 return render(request, 'merchant/dashboard.html')这个装饰器写得虽然简单，但比在每个视图里重复写if判断要整洁得多。Django的login_required只能检查登录状态，检查不了业务角色，所以自定义一个这样的装饰器是电商项目里的高频需求。
3.2 商品上下架与图片处理
商品管理是商家端的核心，我用Django的ModelForm写了添加和编辑功能。商品图片用的是ImageField，需要提前在settings里配好：
MEDIA_URL = '/media/' MEDIA_ROOT = BASE_DIR / 'media'然后项目根urls.py里加一段：
from django.conf import settings from django.conf.urls.static import static if settings.DEBUG: urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)很多新手在这里栽坑——图片明明上传成功了，页面却一直404。原因就是开发环境下的媒体文件路径没有手动映射。加了这个if判断，开发时图片才能正常访问。
商品编辑页里，我用了一个比较实用的做法：表单中把“上架/下架”做成一个下拉选择框，但实际控制商品在用户端可见性的逻辑，不只是看status字段，还必须同时满足stock > 0。也就是说，即使商家忘了下架一个库存为0的商品，用户端也不会再展示它，避免出现“点进详情页才发现没法买”的糟糕体验。
3.3 库存预警：低于阈值自动提醒补货
这就是标题里“智能”二字的第一个落点。水果这种商品，库存管理比普通商品更依赖及时补货。我在商家后台首页放了一张低库存商品列表，逻辑很简单：
low_stock_goods = Goods.objects.filter( status='on', stock__lte=F('safety_stock') ).order_by('stock')这里的核心技巧是F('safety_stock')。它让数据库在SQL层面直接比较stock字段和safety_stock字段的值，而不是先把所有商品查出来再在Python里循环判断。如果商品量大有几千条，用F表达式比把数据拉到内存逐个比较要高效得多。
商家后台首页展示低库存商品的同时，我还给每条商品加了一个“建议补货量”的提示：
suggested_replenishment = max(goods.safety_stock * 2 - goods.stock, 0)这个公式不是一个精确的最优解，但它用“安全库存的两倍作为目标库存，减去当前库存”的思路给出了一个可量化的补货参考值。实际业务里，商家可以根据水果的保质期和进货周期灵活调整，但至少系统给了他们一个决策起点，而不是让他们凭感觉拍脑袋。
3.4 订单发货与退款处理
商家处理订单的核心视图是“待发货订单列表”和“发货操作”。状态流转我用一个字典集中管理：
ORDER_STATUS_FLOW = { 'pending': ['shipped', 'cancelled'], 'shipped': ['completed'], 'refunding': ['refunded'], }每次状态变更前先校验当前状态是否允许转到目标状态，防止用户或者商家跳过流程把订单状态改乱。视图里就是先取订单，判断目标状态在不在合法流转列表里，再更新save。
发货操作记得要更新shipped_at时间戳，方便后续做超时未收货提醒。退款流程里，我在pay_status从refunding变到refunded时，用transaction.atomic()把商品库存加回去。不然退款了但库存没有恢复，商家后台的库存数会越卖越不对。
4. 用户端购物全流程：从逛店到支付
4.1 商品展示、搜索与排序
用户端的首页是商品列表，这里我做了分类筛选、关键词搜索、价格/销量排序三个功能，全部走GET参数：
def goods_list(request): goods_qs = Goods.objects.filter(status='on', stock__gt=0) category_id = request.GET.get('category') keyword = request.GET.get('q') sort = request.GET.get('sort') if category_id: goods_qs = goods_qs.filter(category_id=category_id) if keyword: goods_qs = goods_qs.filter(name__icontains=keyword) if sort == 'price_asc': goods_qs = goods_qs.order_by('price') elif sort == 'price_desc': goods_qs = goods_qs.order_by('-price') elif sort == 'sales': goods_qs = goods_qs.order_by('-sales_count')分页用的Django自带Paginator：
paginator = Paginator(goods_qs, 12) page_obj = paginator.get_page(request.GET.get('page'))页面里循环渲染page_obj，翻页时要把当前的category、q、sort参数原样拼到下一页链接里。这个小细节很影响体验——排序选了“价格从低到高”，点第二页却把排序丢了，用户会觉得很弱智。
4.2 购物车设计与数量联动
购物车页面显示当前用户的购物车项，同时要实时计算总价。我直接对CartItem做关联查询：
cart_items = CartItem.objects.filter(user=request.user).select_related('goods') total_price = sum(item.goods.price * item.quantity for item in cart_items)购物车数量变更我做了个简单的AJAX接口，直接用Django的JsonResponse返回新的小计金额和购物车总价，页面不用刷新。
购物车还有一个隐藏逻辑需要处理：商品下架或者库存变为0后，购物车里的这一项应该标记为“失效商品”。我在渲染购物车页面时做了过滤和提示：
available_items = cart_items.filter(goods__status='on', goods__stock__gt=0) invalid_items = cart_items.exclude(goods__status='on', goods__stock__gt=0)有效商品正常展示、可以下单；失效商品展示“已失效”标签并让用户删除。这种细节是购物车体验好坏的分水岭。
4.3 下单事务与支付联调
下单是整个系统里对数据一致性要求最高的环节。用户点击“提交订单”后，系统要同时完成三件事：生成订单主表和明细、扣减商品库存、加订单到用户“待支付”列表。这三步任何一个失败，都不能让其他步骤成功。
我用transaction.atomic()包住全部逻辑：
from django.db import transaction from django.utils import timezone def create_order(request): if request.method == 'POST': cart_item_ids = request.POST.getlist('cart_item_ids') cart_items = CartItem.objects.filter(id__in=cart_item_ids, user=request.user).select_related('goods') if not cart_items: return JsonResponse({'code': 1, 'msg': '请选择要结算的商品'}) total = 0 with transaction.atomic(): order = Order.objects.create( order_no=generate_order_no(), user=request.user, total_amount=0, receiver=request.POST.get('receiver'), receiver_phone=request.POST.get('receiver_phone'), receiver_address=request.POST.get('receiver_address'), remark=request.POST.get('remark'), ) # 锁定商品行，防止并发超卖 for cart_item in cart_items.select_for_update(): goods = cart_item.goods if goods.stock < cart_item.quantity: raise OrderError(f'商品“{goods.name}”库存不足，当前仅剩{goods.stock}件') subtotal = goods.price * cart_item.quantity OrderItem.objects.create( order=order, goods=goods, goods_name=goods.name, goods_price=goods.price, quantity=cart_item.quantity, subtotal=subtotal, ) goods.stock -= cart_item.quantity goods.sales_count += cart_item.quantity goods.save(update_fields=['stock', 'sales_count']) total += subtotal order.total_amount = total order.save(update_fields=['total_amount']) # 事务提交成功后，清除已购买的购物车项 cart_items.delete() return JsonResponse({'code': 0, 'order_no': order.order_no})这段代码里有两个容易忽略的细节非常关键：
第一个是select_for_update()。在高并发场景下，两个用户同时抢购同一件库存为3的商品，如果不用行锁，可能出现两边都读到stock=3，都以为下单成功，结果实际卖了6件。select_for_update()会在事务内锁住这些商品记录，第二个请求必须等第一个请求事务提交后才能读，从根源上避免超卖。这是电商系统并发安全的核心手段。
第二个是update_fields参数。只更新修改过的字段，减少数据库写入量，也能避免误覆盖其他字段的值。
支付环节我在毕设项目里用的是模拟支付。页面点击“去支付”后，订单状态从unpaid变为paid，记录paid_at时间。如果接真实支付（比如微信支付、支付宝），重点在于回调验签后的幂等处理——支付回调可能因为网络原因重复发送，必须在回调视图里先判断订单是否已经处于paid状态，是的话直接返回成功，不再重复处理。
5. “智能”在哪儿：销量分析与采购建议
5.1 月度销售统计与品类排行
商品卖出去只是第一步，商家真正需要知道的是“什么好卖、什么不好卖、赚了多少”。我在reports应用里写了几张统计报表，核心都是用Django ORM的聚合函数。
月度销售统计的核心查询：
from django.db.models.functions import TruncMonth monthly_sales = ( OrderItem.objects .filter(order__pay_status='paid') .annotate(month=TruncMonth('order__paid_at')) .values('month') .annotate( total_sales=Sum('subtotal'), total_quantity=Sum('quantity'), ) .order_by('month') )TruncMonth是Django提供的时间截断函数，能把一个DateTimeField归一到月份。配合annotate，一条SQL就把每个月的销售额、销售件数全算出来了。
品类排行更直接：
category_sales = ( OrderItem.objects .filter(order__pay_status='paid') .values('goods__category__name') .annotate(total=Sum('subtotal')) .order_by('-total')[:10] )通过goods__category__name跨表链式查询，把订单明细和商品分类关联起来按分类聚合。这样一个排行榜，商家一眼就能看出柑橘类是主力还是水果礼盒才是利润来源。
5.2 基于近7天销量的采购预测
采购预测是这套系统里“智能感”最强的功能。它的思路是：用过去7天的平均日销量，结合商品当前的库存和从下单到到货的采购周期，给出一个建议采购量。
核心代码逻辑：
from datetime import timedelta from django.utils import timezone def purchase_suggestion(goods): today = timezone.now().date() start_date = today - timedelta(days=7) recent_sales = ( OrderItem.objects .filter( goods=goods, order__pay_status='paid', order__paid_at__date__gte=start_date, ) .aggregate(total=Sum('quantity')) ) daily_avg = (recent_sales['total'] or 0) / 7 # 预计补货天数，这里按3天采购周期计算 lead_days = 3 # 安全系数，按1.2倍备货，留出缓冲余量 safety_factor = 1.2 suggested = int(daily_avg * lead_days * safety_factor - goods.stock) return max(suggested, 0)这个公式并不复杂，但它把一个模糊的“该进货了”变成了一个具体的数字。比如某水果近7天卖了49斤，日均7斤，采购周期3天，安全系数1.2，建议备货量就是7×3×1.2-当前库存。如果当前库存还有20斤，那么建议采购量大约是5斤；如果库存只剩5斤，建议采购量就是20斤。
这套逻辑放在真实生鲜场景里，商家可以再结合实际天气、节假日、促销活动等因素做调整，但系统给出的建议值已经能覆盖大多数正常经营场景下的采购决策。
6. 高频踩坑实录与排查技巧
6.1 mysqlclient安装失败与数据库连接坑
这是Windows下最常见的第一个拦路虎。装mysqlclient报C++编译错误的，直接换方案：装PyMySQL然后在__init__.py里做一次适配。如果连PyMySQL都装不上，更省事的方式是把数据库换成SQLite先开发，最后部署再切MySQL。Django的ORM屏蔽了绝大部分数据库差异，开发期用SQLite、生产用MySQL是完全可行的路线。
6.2 图片上传后一直404
上传成功但访问404，九成是开发环境没有配媒体路由。在项目urls.py里加上：
if settings.DEBUG: urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)如果部署到服务器后图片还是404，那就是Nginx没有把/media/路径指向MEDIA_ROOT目录。需要在Nginx配置里加一段location规则：
location /media/ { alias /your_project_path/media/; }6.3 QuerySet性能陷阱：N+1查询
商家后台订单列表，我第一次写的版本循环里查地址、查商品，页面加载要等好几秒。后来用select_related解决：
orders = Order.objects.filter(order_status='pending').select_related('user').prefetch_related('items__goods')需要注意：select_related适用于单个对象关联（ForeignKey、OneToOne），prefetch_related适用于集合关联（ManyToMany、反向ForeignKey）。混着用效果最好。
6.4 支付回调重复通知与幂等处理
真实支付接口的回调通知可能因为网络抖动发多次。处理方式很简单——更新订单状态前先查当前状态：
order = Order.objects.select_for_update().get(order_no=order_no) if order.pay_status == 'paid': return JsonResponse({'code': 0, 'msg': 'success'}) order.pay_status = 'paid' order.paid_at = timezone.now() order.save(update_fields=['pay_status', 'paid_at'])用select_for_update加行锁，重复回调到达时，后一个会等前一个提交完成，然后读到paid状态直接返回成功。既不重复加库存，也不会把订单状态改乱。
6.5 部署阶段的静态文件与ALLOWED_HOSTS
开发环境一切正常，一上服务器就页面没样式。这几乎都是Django静态文件没有collectstatic。部署前执行：
python manage.py collectstatic然后在settings里设好STATIC_ROOT，Nginx里配/static/的location。另外，线上环境必须把ALLOWED_HOSTS配成你的域名或IP，否则Django会拒绝请求，报DisallowedHost错误。
我最初部署时ALLOWED_HOSTS漏配了服务器IP，排错排了整整一晚上，最后才发现是这种“看一眼就觉得不会错但实际漏了”的配置项。所以代码之外，配置文件里的每一行都值得仔细过一遍。
结尾
项目做到最后，我个人的最大体会是：Django这个框架本身不难，难的是把业务逻辑想清楚。比如“库存预警阈值怎么设”“订单状态怎么流转才算安全”“支付回调怎么保证幂等”，这些问题在框架文档里找不到答案，但它们恰恰是系统能不能真正落地使用的决定性因素。如果你正在做类似的商城项目，不妨先不急着写代码，拿一张纸把角色的操作路径画出来，把每种状态的可能流转列出来，再来写Django代码，你会发现顺很多。后面有时间的话，我还会把消息通知、优惠券、秒杀限购这几个模块补进去，让这套系统的业务闭环更完整一些。
