Django日用品商场系统开发实战：从库存并发到订单部署

搞日用品商场系统这种项目，最难的不是写代码，而是没想清楚边界就开始堆功能。我前前后后做过几个类似的电商项目，也带过不少新人，发现大家最常犯的错就是把“商场系统”当成“电商平台”来设计——又是推荐算法又是秒杀系统，最后连个正常下单都跑不通。这篇文章就围绕“基于Django的日用品商场系统”这个主题，把我实际做过的东西、踩过的坑、以及为什么这么做，一次性讲清楚。

如果你正打算用Django做个日用品商城练手或者应付毕业设计、公司内部系统，这篇文章会比较对路。我会从需求梳理、模型设计、核心链路、并发处理、部署上线这几个维度依次展开，尽量让新手能照着复现，让有经验的人也能有收获。

1. 先说清楚这个系统到底要解决什么问题

1.1 商场系统不是电商平台，业务边界要划清

日用品商场系统，核心是“日用品”三个字。这意味着什么？意味着商品单价低、品类多、库存变化频繁、用户下单频次高但单笔金额不大。它跟京东、淘宝那种综合电商的差别非常大——你不需要复杂的商家入驻体系、不需要分销裂变、不需要个性化推荐引擎。你需要的其实是把“商品展示-加入购物车-下单支付-库存扣减-订单管理”这条主链路跑稳定。

我见过不少项目把自己搞死的例子：上来就上Redis做购物车、上Celery做异步通知、上ElasticSearch做商品搜索，结果项目拖了三个月还在调环境。日用品商场的第一步，是用Django把最核心的闭环做出来，其余的都是后话。

所以在动手写代码之前，我强烈建议你先画一张业务流程图，明确系统里有哪几类角色。以日用品商场为例，一般只需要两类：

• 前台用户：浏览商品、搜索、加购物车、下单、支付、查看订单、申请售后。
• 后台管理员：管理商品分类、商品信息、库存、订单处理、发货。

这两类角色的权限边界一定要清晰。Django自带的auth应用和admin后台，恰好能覆盖这两块——User模型管前台用户，admin后台给运营用，没必要重复造轮子。

1.2 核心角色与主流程：商品、订单、库存三条线的交汇

把主流程拆开来看，整个系统的核心数据流是这样的：

1. 用户在商品列表页看到商品 → 点击详情 → 加入购物车 → 提交订单。
2. 系统校验库存 → 扣减库存 → 生成订单 → 发起支付。
3. 支付成功后 → 更新订单状态 → 通知发货。
4. 管理员发货 → 用户确认收货 → 订单完成。

在这个流程里，最容易被忽略但又最关键的点是：库存扣减的时机。扣早了，用户还没支付货就被锁死；扣晚了，超卖问题直接让你赔钱。这个我后面单独开一节讲。

所以第一章的结论是：先认清项目的规模与边界，再决定技术方案。Django适合这个场景，不是因为它是“最好的框架”，而是因为它的ORM、Admin、认证体系、模板引擎刚好能覆盖日用品商场的大部分需求，而且踩坑资料多，遇问题能快速找到答案。

2. Django的取舍：为什么这个项目适合用它来做

2.1 与Flask、Spring Boot对比后的真实选择

选技术栈这事，很多新手容易陷入“谁火用谁”的误区。我个人的习惯是先列需求，再反推技术选型。日用品商场系统的需求特性是：

• 数据模型多且关联复杂（用户、商品、SKU、购物车、订单、支付流水、库存流水）。
• 需要后台管理界面，运营要能快速录入商品、处理订单。
• 权限体系要清晰（用户端和管理端），但不需要特别复杂的细粒度权限。
• 开发周期短，团队可能就一两个人。
• 后期有一定扩展空间，但不指望一开始就支撑千万级并发。

基于这几点，我对比过Flask和Spring Boot：

结论很明确：Django在日用品商场这种“标准业务系统”里，是单兵或小团队作战效率最高的选择。Flask的灵活在复杂业务里反而容易变成维护负担，Spring Boot则更适合有专职运维和企业级规范的大团队。

2.2 Django自带能力正好覆盖商场系统的“脏活累活”

很多人嫌Django“太重”，其实这个“重”恰好是优势。举个例子，商场系统必然需要一套可用的后台管理——Django Admin直接导入模型就能生成增删改查界面，商品分类、订单管理、用户管理这些模块，运营当天就能上手用。你如果拿Flask写，这套后台至少得多花两三天。

再比如用户登录认证。商场系统需要注册、登录、登出、找回密码，Django自带的auth应用和session机制直接能跑通。虽然现在流行JWT，但传统商场的网页端场景，session其实更简单可靠，我在第6章会细说。

还有表单处理。商品搜索、筛选、用户填写收货地址这些场景，Django Form和ModelForm能帮你省掉大量手动处理POST请求、校验数据、渲染错误信息的代码。我见过太多人一上来就前后端分离，React + DRF搞半天，结果连个表单校验都写不利索。这里不是反对前后端分离，而是想强调：技术选型要匹配团队能力和项目阶段。日用品商场项目，先用Django模板+少量AJAX把产品跑起来，比一开始就上工程化框架要务实得多。

3. 数据模型设计：把商品、SKU、订单、库存流水一次建模到位

3.1 商品与SKU分离设计的必要性

商场系统的地基是数据模型。我见过最糟糕的设计是把所有字段塞进一张Product表，颜色、尺寸、库存都做成字段，结果加一个新规格就得改表结构。正确的做法是把“商品”和“SKU”分开。

我举个例子。你在卖一瓶洗发水，它有“400ml”和“800ml”两个规格，这两个规格价格不同、库存不同。这时候：

• Product（商品）代表洗发水这个抽象商品，包含名称、品牌、详情描述、主图。
• SKU（库存量单位）代表具体规格，包含规格名称、价格、库存、SKU编码。

Django模型可以这样设计：

class Product(models.Model): name = models.CharField(max_length=200, verbose_name="商品名称") category = models.ForeignKey(Category, on_delete=models.CASCADE, verbose_name="分类") description = models.TextField(verbose_name="商品详情", blank=True) main_image = models.ImageField(upload_to="products/", verbose_name="主图") is_on_sale = models.BooleanField(default=True, verbose_name="是否上架") created_at = models.DateTimeField(auto_now_add=True) class Meta: verbose_name = "商品" verbose_name_plural = verbose_name class SKU(models.Model): product = models.ForeignKey(Product, on_delete=models.CASCADE, related_name="skus", verbose_name="所属商品") spec = models.CharField(max_length=100, verbose_name="规格，如400ml/800ml") price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="售价") stock = models.PositiveIntegerField(default=0, verbose_name="库存") sku_code = models.CharField(max_length=50, unique=True, verbose_name="SKU编码") is_active = models.BooleanField(default=True, verbose_name="是否启用")

为什么要加is_active？因为商场运营经常要临时下架某个规格（比如某批次质检没过），但又不想删除数据影响历史订单。软删除的思路在日用品这种更新频繁的场景里特别实用。

价格为什么用DecimalField而不是FloatField？这是很多新手容易踩的坑。浮点数在计算0.1+0.2的时候会得到0.30000000000000004，金额算错哪怕是几分钱，对账的时候都够你查一晚上。DecimalField存的是定点数，配合Decimal类型计算，在电商项目里是标配。

3.2 购物车、订单、订单项的关系与字段取舍

购物车有两种实现方案：存在服务端用Cart模型，或者存浏览器用Cookie。日用品商场用户会跨设备使用，所以我推荐服务端方案。模型可以这样设计：

class Cart(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE, verbose_name="用户") sku = models.ForeignKey(SKU, on_delete=models.CASCADE, verbose_name="商品SKU") quantity = models.PositiveIntegerField(default=1, verbose_name="数量") selected = models.BooleanField(default=True, verbose_name="是否勾选") updated_at = models.DateTimeField(auto_now=True) class Meta: unique_together = ("user", "sku")

unique_together保证了同一个用户同一个SKU只有一条记录，加购重复商品只会增加数量，这个细节能省去前端好多判断。

订单这一层是核心中的核心。一个订单对应一个用户、多个订单项，所以需要Order和OrderItem两张表。另外我强烈建议加一张OrderLog表记录订单状态变更历史。为什么？因为商场用户的纠纷率比你想象的高，今天说没收到货，明天说少发了一件，没有日志你根本没法追溯。

class Order(models.Model): ORDER_STATUS = ( ("pending", "待付款"), ("paid", "待发货"), ("shipped", "已发货"), ("completed", "已完成"), ("cancelled", "已取消"), ) order_no = models.CharField(max_length=32, unique=True, verbose_name="订单编号") user = models.ForeignKey(User, on_delete=models.PROTECT, verbose_name="用户") total_amount = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="订单总额") status = models.CharField(max_length=20, choices=ORDER_STATUS, default="pending", verbose_name="订单状态") receiver_name = models.CharField(max_length=50, verbose_name="收货人") receiver_phone = models.CharField(max_length=20, verbose_name="联系电话") receiver_address = models.CharField(max_length=200, verbose_name="收货地址") created_at = models.DateTimeField(auto_now_add=True) paid_at = models.DateTimeField(null=True, blank=True, verbose_name="支付时间") def __str__(self): return self.order_no

注意on_delete=models.PROTECT——用户表被删的时候，订单数据不能被级联删除。商场系统的订单是财务凭证，物理删除是大忌。这个细节，新手十有八九会忽略。

3.3 Admin后台：先让运营能干活，再谈用户体验

Django Admin的价值被很多人低估了。日用品商场的运营需求非常落地：上架商品、改价格、调库存、发货。这些操作如果用传统网页开发，每个功能都得单独写个页面，费时费力。Django Admin里只需要简单配置就能满足：

@admin.register(Product) class ProductAdmin(admin.ModelAdmin): list_display = ("name", "category", "is_on_sale", "created_at") list_filter = ("category", "is_on_sale") search_fields = ("name",) inlines = [SKUInline] # 在商品页直接编辑SKU

inlines这个配置特别实用，运营在商品编辑页就能直接看到并维护所有SKU，不用跳来跳去。加上list_filter和search_fields，几百上千个商品也能快速定位。

后台这块，我用下来比较推荐的做法是：先直接用默认Admin跑通业务流程，再按运营反馈逐步定制。不要一开始就装django-admin-interface或者grappelli这类美化插件，能让业务流程跑通比好看重要得多。等真需要更好看的后台界面了，再考虑定制也不迟。

4. 核心链路实现：从商品列表到订单支付的完整代码走读

4.1 商品列表与搜索筛选的实现思路

商品列表页是用户进店的第一站，必须保证响应快、筛选直观。Django ORM在数据量不大的情况下，性能足够，关键是别写出N+1查询。

一种典型的错误写法是：

# 不推荐：每个商品都查询一次分类和SKU products = Product.objects.filter(is_on_sale=True) for product in products: print(product.category.name) # 导致额外的SQL查询

推荐的做法是使用select_related和prefetch_related：

products = Product.objects.filter(is_on_sale=True).select_related("category").prefetch_related("skus")

select_related适用于一对一、多对一关系，prefetch_related适用于多对多、一对多关系。这一行代码就能把SQL查询数量从几十次降到两次，商城列表页的响应时间提升非常明显。

搜索筛选这块，日用品商场最常见的场景是按分类筛选、按价格区间筛选、按关键词搜索。用Django的ORM写起来很简洁：

products = products.filter(category_id=category_id) if category_id else products products = products.filter(price__gte=min_price) if min_price else products products = products.filter(price__lte=max_price) if max_price else products products = products.filter(name__icontains=keyword) if keyword else products

icontains是大小写不敏感的模糊查询，中文搜索场景下够用了。等数据量真的到几十万商品了，再考虑接入ElasticSearch或PostgreSQL全文检索，前期完全没必要。

4.2 购物车模块：session方案与数据库方案的取舍

购物车我没有用Django session，而是直接落库。原因有二：

1. 日用品购物车里的商品数量多、单价低，用户经常隔几天才结算，session过期或换设备都会导致购物车丢失。
2. 落库之后可以很方便地做“已登录用户购物车合并”和“运营端查看热销加购数据”。

核心逻辑就三块：加购、改数量、删除。加购的代码要注意“存在即增加数量”的处理：

def add_to_cart(request, sku_id): sku = get_object_or_404(SKU, id=sku_id, is_active=True) cart_item, created = Cart.objects.get_or_create( user=request.user, sku=sku, defaults={"quantity": 1} ) if not created: cart_item.quantity += 1 cart_item.save() return redirect("cart:detail")

注意get_or_create这个ORM方法，它能避免“先查再创建”之间的竞态条件。虽然购物车加购并发概率不高，但养成用原子操作的习惯没坏处。

4.3 下单接口与事务边界

从购物车到生成订单，是整个系统里最需要谨慎对待的环节。步骤拆开来看：

1. 获取用户勾选的购物车项，计算总金额。
2. 校验每个SKU的库存是否充足。
3. 扣减库存（这一步是超卖重灾区，下一章重点讲）。
4. 生成订单和订单项。
5. 清空购物车中已下单的商品。

这五步要么全部成功，要么全部失败，所以必须包在一个事务里。Django提供了一个上下文管理器：

from django.db import transaction def create_order(request): cart_items = Cart.objects.filter(user=request.user, selected=True).select_related("sku") with transaction.atomic(): order = Order.objects.create( user=request.user, order_no=generate_order_no(), total_amount=calculate_total(cart_items), ... ) for item in cart_items: sku = item.sku if sku.stock < item.quantity: raise ValueError(f"商品 {sku.sku_code} 库存不足") sku.stock -= item.quantity sku.save() OrderItem.objects.create(order=order, sku=sku, quantity=item.quantity, price=sku.price) cart_items.delete()

这段代码看起来很完美，但注意：这里埋了一个并发隐患。如果两个请求同时读到stock=5，都判断5 >= 3成立，然后都执行sku.stock -= 3，最终库存变成-1。这就是经典的超卖问题。下一章专门讲怎么解决。

5. 防超卖与库存一致性：最容易被新手忽略的并发问题

5.1 为什么直接减库存会出错——并发场景还原

大多数新手第一次写商城项目的时候，都会写成上面那种“读库存-判断-扣减”三步走。在单用户测试的时候，一切正常。直到上线后某个商品做促销，多个用户同时下单，你就会发现库存变成了负数，然后被运营骂到怀疑人生。

问题出在哪？Django的ORM查询和更新包装在transaction.atomic()里，看起来是一个事务，但事务默认的隔离级别是“读已提交”（READ COMMITTED）。这意味着两个并发事务可以同时读到同一个库存值，然后各自处理。事务A读到stock=5，事务B也读到stock=5，A扣3变成2，B扣3也基于5扣，最终把库存写成了2，但实际卖出了6件。

5.2 三种库存扣减方案对比：乐观锁、悲观锁、Redis原子操作

解决并发扣库存，业界主流是三种方案：

Django里实现乐观锁，常见做法是用F()表达式配合条件更新：

from django.db.models import F # 只用一条UPDATE语句，数据库自己保证原子性 updated = SKU.objects.filter(id=sku.id, stock__gte=item.quantity).update(stock=F("stock") - item.quantity) if updated == 0: raise ValueError("库存不足")

这种写法利用数据库行锁，UPDATE本身是原子操作，不会出现丢失更新的问题。推荐大多数日用品商场用这种方案。

悲观锁在Django里用select_for_update()：

with transaction.atomic(): sku = SKU.objects.select_for_update().get(id=sku.id) if sku.stock < item.quantity: raise ValueError("库存不足") sku.stock -= item.quantity sku.save()

select_for_update()会锁定这一行，直到事务结束，其他事务想读这行会被阻塞。优点是不会扣错，缺点是在高并发下会累积锁等待。

5.3 实际方案：Django事务 + F()表达式 + 库存流水记录

我最终给日用品商场系统推荐的是组合方案：主线用乐观锁（F()表达式），同时加一张库存流水表StockLog。为什么加流水表？因为你要能审计“为什么库存少了”。比如运营怀疑系统被人批量刷单，你得能查出来每次扣减是哪个订单、什么时间、扣了多少。

# 减库存 updated = SKU.objects.filter(id=sku_id, stock__gte=quantity).update(stock=F("stock") - quantity) if not updated: raise ValueError("库存不足") # 记录流水 StockLog.objects.create( sku_id=sku_id, order=order, change=-quantity, remark="下单扣减" )

这里有个小优化：update(stock=F("stock") - quantity)要求stock__gte=quantity，两步合在一个SQL里，既做了并发控制又做了库存判断。实测在日用品商城这种并发量下，这个方案跑得很稳，也不需要引入Redis增加运维复杂度。

关于F()表达式，我自己一开始也踩过坑，以为只要用了F()就万事大吉。后来发现这样写还是有个问题：订单里如果包含多个SKU，某个SKU扣减失败时，其他SKU已经扣减成功了，整个事务需要回滚。所以F()表达式必须配合transaction.atomic()使用，任何一个SKU失败，整个事务一起回滚，这样才能保证订单和库存的一致性。

6. 订单状态机设计：从待付款到已完成的状态流转与异常处理

6.1 状态字段不要乱存，状态机会让你的代码少一半Bug

订单状态是商场系统命脉。如果只是简单用一个字符串字段随便赋值，短期看起来没问题，时间一长一定会有脏数据——比如“已退款”的订单还能“发货”，这会直接导致财务对账出问题。

我建议把所有状态流转集中管理，定义一个“状态机”约束，写在模型层，这样谁都绕不过去：

class Order(models.Model): STATUS_TRANSITIONS = { "pending": ["paid", "cancelled"], "paid": ["shipped", "cancelled"], "shipped": ["completed", "returning"], "returning": ["completed", "refunded"], "completed": [], "cancelled": [], "refunded": [], } def transition_to(self, new_status): if new_status not in self.STATUS_TRANSITIONS[self.status]: raise ValueError(f"订单状态不允许从 {self.status} 转为 {new_status}") if new_status == "paid": self.paid_at = timezone.now() self.status = new_status self.save(update_fields=["status", "paid_at", "updated_at"]) OrderLog.objects.create(order=self, old_status=self.status, new_status=new_status)

这里又一个实用细节：状态变更时必须写OrderLog。我在开发这套系统的时候，曾经因为没加日志，被一个用户投诉“订单莫名其妙消失了”。排查了半天，最终靠数据库的django_auditlog插件才恢复出操作记录。自那以后，凡是有状态变化的模型，我都强制加日志，这个习惯救过我好几次。

6.2 支付回调与订单状态更新的幂等处理

对接第三方支付（微信/支付宝）时，支付回调是核心。回调接口最大的特点是：可能被调用多次。网络超时、支付平台重试、你自己的代码重复消费消息，都会导致同一笔订单被回调多次。如果不做幂等处理，订单金额会重复入账，或者状态被打回“待支付”。

最直接的做法是利用数据库唯一约束和状态校验：

def handle_payment_callback(order_no, payment_amount): with transaction.atomic(): order = Order.objects.select_for_update().get(order_no=order_no) if order.status == "paid": # 已处理过，直接返回成功，避免重复操作 return True if order.total_amount != Decimal(payment_amount): # 金额不一致，记录日志，报警 return False order.transition_to("paid") return True

select_for_update()在这里的作用不只是锁行，更是保证“检查状态-更新状态”是一个原子操作。两个回调同时进来时，第一个拿到锁，第二个会一直等到第一个事务结束，然后再检查状态发现已经是“paid”，直接跳过。这就是幂等。

这个环节的实际经验是：回调接口的返回值别乱写。微信、支付宝的回调处理成功返回success字符串，失败返回其他内容。很多人图省事，处理失败也返回success，结果支付平台不再重试，订单就一直卡在“待付款”。正确的做法是：处理成功返回success，处理失败时返回具体错误信息，让支付平台稍后再试。

7. 线上部署与性能优化：从开发机到服务器的最后一公里

7.1 部署组合：Nginx + Gunicorn + MySQL的实践配置

开发环境用runserver没问题，上线就一定要换正式的WSGI服务器。我的标准组合是Nginx + Gunicorn + MySQL，部署在Ubuntu服务器上。

Gunicorn配置很简单，核心是调整worker数量：

# gunicorn.conf.py bind = "127.0.0.1:8000" workers = 4 worker_class = "gevent" timeout = 60

worker数量经验值是CPU核心数 × 2 + 1。我在一台2核4G的云服务器上，开了5个worker，扛住了商场日常流量加日常促销。如果访问量持续上涨，优先加数据库索引和缓存，而不是无限加worker。

Nginx配置要注意的是静态文件和媒体文件走Nginx直出，别让Django处理图片请求：

location /static/ { alias /var/www/myshop/static/; expires 30d; } location /media/ { alias /var/www/myshop/media/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }

如果Django启用了HTTPS，X-Forwarded-Proto这个header尤其重要，否则Django会以为请求是HTTP，导致CSRF和重定向出问题。

7.2 配置分离、日志与最容易被忽略的时区问题

部署阶段最容易踩坑，我一个个说。

第一，配置分离。我见过太多人把数据库密码、SECRET_KEY直接写在settings.py里然后推到Git仓库。正确做法是使用环境变量管理敏感配置：

import os SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY") DEBUG = os.environ.get("DJANGO_DEBUG", "False") == "True" ALLOWED_HOSTS = os.environ.get("DJANGO_ALLOWED_HOSTS", "").split(",")

开发环境用.env文件，生产环境用服务器环境变量注入。这样代码仓库里永远不会有敏感信息。

第二，日志配置。Django默认的日志输出到标准输出，在Gunicorn环境下会进系统日志，排查问题非常别扭。建议设置一个文件日志，既方便按日期切割，也方便用tail -f实时查看：

LOGGING = { "version": 1, "handlers": { "file": { "class": "logging.handlers.TimedRotatingFileHandler", "filename": "/var/log/myshop/django.log", "when": "midnight", "backupCount": 30, } }, "root": {"handlers": ["file"], "level": "INFO"}, }

第三，时区问题。这个我印象太深了。第一次部署上线，运营反馈“订单时间比本地时间早了8小时”。查了半天发现是TIME_ZONE没设对：

TIME_ZONE = "Asia/Shanghai" USE_TZ = True

但注意，USE_TZ = True的情况下，数据库存的是UTC时间，框架渲染时会自动转成本地时间。如果你非要在代码里手动用datetime.now()去生成时间戳而不经过django.utils.timezone.now()，就会造成时间错乱。凡是涉及订单、支付回调时间，统一用timezone.now()，准没错。

8. 上线后实测踩过的一些坑，还有几个实在建议

8.1 问题一：CSRF校验导致移动端支付回调失败

第一次对接微信支付的时候，回调接口一直返回500。折腾了一个多小时，最后发现是Django的CsrfViewMiddleware把支付平台的POST请求给拦了。微信支付回调是没有带CSRF Token的，Django默认对所有POST请求做CSRF校验。

解决方案有两种。一种是用@csrf_exempt装饰器：

from django.views.decorators.csrf import csrf_exempt @csrf_exempt def payment_callback(request): ...

另一种是配置urls.py时用csrf_exempt包一层。注意，这个接口绝对不能省略CSRF防护后还暴露其他敏感操作，只对支付回调这种第三方服务调用方的特殊场景使用。

8.2 问题二：购物车数据被清空

上线一周后，有用户反应购物车商品莫名其妙没了。查日志发现，这些用户的购物车记录确实存在，但用户在A设备加购，B设备登录后购物车是空的。

原因在于我用了Django默认的session机制，而商品数据存在数据库表里，用户在一台设备登录后，另一台设备的session被覆盖了。解决方法是给购物车数据加一层用户ID的关联，而不是完全依赖session。更稳妥的方案是设计一个“游客购物车合并”逻辑：用户未登录时用本地购物车，登录后把本地购物车入库。这一步虽然要写一点代码，但体验提升非常明显。

8.3 给后来者的一些实在建议

做日用品商场系统，从开发到上线，我最后总结几个最想分享的点：

1. 先抄再超。市面上已经有无数开源的商城项目，先照着写一遍，理解别人为什么这么设计，再动手改造。闭门造车效率最低。

2. 数据库设计多花一倍时间，后期省三倍时间。尤其是Order和StockLog这类核心表，字段设计错了，后面改起来全是哀嚎。

3. 不要过早引入分布式组件。日用品商场的并发量在早期根本到不了需要Redis、消息队列扛的水平，先把单机Django做到极致，性能瓶颈出现了再扩展。

4. 一定要给自己留后路。上线前把DEBUG=False、SECRET_KEY从代码里抽出去、配置好日志切分，这三件事做了，以后排查问题会轻松非常多。不要问我怎么知道的，说多了都是泪。

我用Django写过不少项目，日用品商场系统是其中“正反馈来得最快”的一个——做的东西离业务近，用户用得勤，改起来也顺手。相比那些三天两头换技术栈的项目，这套朴素的技术组合反而最稳定。希望这篇文章能让你少走一些弯路，把这套系统扎扎实实跑起来。