企业官网建设流程全解析

1. 先谈业务：陶瓷商品的特殊性如何决定系统设计

1.1 陶瓷品类对商城系统的三个特殊要求

很多人看到"陶瓷销售商城"这个题目，第一反应是：这不就是套个现成的电商系统，换换图、改改标题就能上线吗？我第一次接这个需求的时候也这么想，但真正做下去才发现，陶瓷这个品类对系统的要求，比大多数标准电商方案能承受的要大得多。

第一个特殊要求是商品属性的离散性。工业标品的SKU可以精确到颜色、尺寸、型号，同一批几百上千件没有任何区别。但陶瓷不一样，尤其是有手工成分的产品：釉色的深浅、口径的大小、容量的高低，每件之间都可能存在差异。同一个窑次烧出来的同款杯子，窑位不同，釉面效果都会不一样。这意味着商品规格没办法只用几个固定字段撑住，数据模型要有足够的弹性去存住"这件东西的独特性"。

第二个特殊要求是库存的非连续性。流水线产品卖完可以随时补货，手工陶瓷只能等下一窑。很多小众窑口一个月才烧一次，一窑能出的成品数量也有限。如果后台只显示一个库存数字，运营完全没法判断"缺货之后还要等多久"。所以在实际建模时，我建议在库存上记录批次或窑次信息，哪怕只是一个字符串字段，对运营的帮助也非常大。

第三个特殊要求是售后压力。陶瓷易碎，物流破损率比服装、数码产品高一个量级，退换货是高频场景。订单状态机如果不在设计之初就考虑退款、补发、拒收这些分支，等上线以后遇到第一波破损投诉，代码会改得非常痛苦。

1.2 一个陶瓷商城必须承载的业务闭环

基于上面这三点，我把这个平台的业务拆成了四个核心闭环：

1. 商品闭环：分类浏览、SPU展示、SKU规格选择、详情介绍、搜索筛选。
2. 交易闭环：购物车、下单、锁库存、支付回调、订单查询。
3. 履约闭环：发货、物流跟踪、签收、退款、售后。
4. 运营闭环：商品上下架、批量改价、库存预警、活动推荐、销售统计。

这四条闭环里，商品闭环和交易闭环是开发量最大的，履约闭环是资金风险最高的，运营闭环决定了平台上线后能不能高效运转。下面的内容就按这条主线，把我实际做这个项目时的设计和踩过的坑展开讲。

2. 技术选型与工程初始化：Django、数据库与缓存的落地选择

2.1 Python加Django的组合，到底赢在哪

技术选型阶段，我的判断标准只有一条：这个项目是要交付运营的，不是做技术实验，所以要选"什么都能干、踩坑成本最低"的组合。

Python加Django正好符合。Django自带ORM、模板引擎、Admin后台、表单处理、认证系统和Session管理，这些能力恰好是交易系统的地基。尤其是Admin后台，开发期直接拿给运营录测试商品，能省出好几天搭后台的时间。

如果换Flask，用户注册登录、后台管理、CSRF防护这些都要自己拼，短期内看起来轻巧，项目一长就会变成一堆半成品的缝合。FastAPI适合纯API服务和高并发异步场景，但陶瓷商城这种偏内容展示、需要SEO友好页面的项目，用Django的服务端渲染再配合必要的前端增强，性价比高得多。

如果你坚持前后端分离，Django加Django REST Framework（DRF）也没有问题。DRF的序列化器、视图集、权限控制都是现成的，和Django的ORM配合得很顺。

2.2 版本、数据库与Redis的选型细节

我的实际选择是Django 4.2 LTS加Python 3.11。选LTS版本的原因很直接：Django大版本升级经常带破坏性变更，生产环境冒不起这个险。4.2的官方维护周期覆盖到2026年，对一个商城系统来说足够了。

数据库用MySQL 8.0，而且从开发第一天就连接MySQL，不碰SQLite。这是很多项目的大坑：开发时用SQLite风平浪静，部署到MySQL后各种约束行为不一致，排查起来极其痛苦。既然上线迟早要换，不如一开始就统一。

Redis在这个项目里承担两类职责：第一是商品列表页和详情页的缓存，第二是配合Celery做订单超时关闭、支付回调处理这些异步任务。商城页面的访问热点非常集中，一天里90%的请求可能都打在首页和商品详情页上，这两个页面不缓存的话，数据库很快会成为瓶颈。

2.3 初始化阶段最容易翻车的三个配置

Django项目创建完，先把settings里的时区和语言改掉，这是第一件事。

LANGUAGE_CODE = 'zh-hans' TIME_ZONE = 'Asia/Shanghai' USE_I18N = True USE_TZ = True

新同学最容易漏的是USE_TZ。默认情况下Django是启用时区的，所有模型里的DateTimeField存进MySQL的都是UTC时间，展示时如果不转换，订单创建时间就会比真实时间慢八小时。Django模板里自带的timezone过滤器可以解决，关键是心里要有这根弦。

第二件事是MySQL连接的字符集。建库时一定要指定utf8mb4，连接时也要显式传charset，否则商品描述里出现生僻字、特殊符号会直接写入失败。

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'ceramic_mall', 'USER': 'mall_user', 'PASSWORD': 'your_db_password', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', }, } }

注意这类密码不要直接写死在代码里，用环境变量读取，避免误提交到Git仓库。第三件事是媒体文件和静态文件的目录分开，商品图片属于上传的媒体文件，不能和静态资源混在一起，否则上线时静态文件的收集策略会让你头疼。

3. 商品中心建模：SPU、SKU与库存扣减的核心设计

3.1 先分清SPU和SKU，再写模型

这是整个项目最关键的一步。很多人建商品表一上来就一个表管所有，几百个字段堆在一起，改一次痛一次。

标准做法是把商品拆成两层：SPU是"款"，SKU是"具体可卖的商品单元"。举个例子，页面展示的"龙泉青瓷手作主人杯"是SPU，而"粉青釉·300ml·直筒款"是SKU。顾客在详情页选择规格，选中的每一个组合都对应一个SKU，价格和库存挂在SKU上，SPU只负责承载公共信息。

有一种错误做法是把规格信息拆成一张"规格名-规格值"表，然后用代码去拼。这种方案在早期电商系统里很常见，但对陶瓷品类来说过于复杂。我建议用JSONField来存规格属性，比如{"釉色": "粉青", "容量": "300ml"}，够灵活，改动规格不需要做数据库迁移。代价是没法在数据库层面对规格做精细过滤，但实际的搜索需求通常落在分类和名称上，影响不大。

3.2 分类、商品、SKU的落地代码

分类模型先搭好，支持二级分类就够了，陶瓷品类一般不会超过三层：

class Category(models.Model): name = models.CharField('分类名称', max_length=50) slug = models.SlugField('URL标识', max_length=80, unique=True) parent = models.ForeignKey( 'self', verbose_name='父级分类', null=True, blank=True, on_delete=models.CASCADE, related_name='children' ) sort_order = models.IntegerField('排序权重', default=0) class Meta: ordering = ['sort_order', 'id'] verbose_name = '商品分类' verbose_name_plural = verbose_name

商品SPU模型要特别注意状态字段，我习惯用IntegerChoices而不是字符串，后面做批量上下架操作时非常方便：

class Product(models.Model): class Status(models.IntegerChoices): DRAFT = 0, '草稿' ON_SALE = 1, '在售' OFF_SALE = 2, '下架' name = models.CharField('商品名称', max_length=200) subtitle = models.CharField('商品副标题', max_length=300, blank=True) category = models.ForeignKey(Category, on_delete=models.PROTECT, verbose_name='商品分类') cover = models.ImageField('封面图', upload_to='products/cover/%Y/%m/') gallery = models.JSONField('图集', default=list, blank=True) detail = models.TextField('详情描述', blank=True) status = models.SmallIntegerField('状态', choices=Status.choices, default=Status.DRAFT) is_featured = models.BooleanField('首页推荐', default=False) created_at = models.DateTimeField('创建时间', auto_now_add=True) updated_at = models.DateTimeField('更新时间', auto_now=True) class Meta: ordering = ['-created_at'] verbose_name = '商品' verbose_name_plural = verbose_name

SKU是价格和库存的载体：

class Sku(models.Model): product = models.ForeignKey(Product, on_delete=models.CASCADE, related_name='skus') name = models.CharField('SKU名称', max_length=200) spec = models.JSONField('规格属性', default=dict) sku_code = models.CharField('SKU编码', max_length=50, unique=True) price = models.DecimalField('售价', max_digits=10, decimal_places=2) origin_price = models.DecimalField('划线价', max_digits=10, decimal_places=2, null=True, blank=True) stock = models.IntegerField('可售库存', default=0) locked_stock = models.IntegerField('锁定库存', default=0) is_active = models.BooleanField('启用状态', default=True) sort_order = models.IntegerField('排序', default=0) batch_note = models.CharField('批次/窑次备注', max_length=200, blank=True) class Meta: ordering = ['sort_order', 'id'] verbose_name = 'SKU' verbose_name_plural = verbose_name

这里我特意加了batch_note字段，就是前面提到的"批次/窑次备注"。手工陶瓷补货不连续，运营需要知道这批卖完下批从哪里来，这个字段能省掉很多沟通成本。

3.3 stock与locked_stock：双库存设计的业务逻辑

库存字段我拆成了两个：stock代表可售库存，locked_stock代表已被订单锁定但还没发货的库存。这套设计解决的是"下单后库存被占用"的问题。

时间线是这样的：用户下单成功，系统把stock减一、locked_stock加一；支付成功不做库存变动；仓库发货时，locked_stock减一；如果订单超时取消或用户主动取消，locked_stock减一、stock加一，把库存还给可售池。

这么做的好处是，后台任何时候都能看到一个准确信号：locked_stock高，说明有大量订单待发货，仓库要赶紧处理；locked_stock长期居高不下，就要排查是不是有支付成功的订单卡住了。

扣库存的代码一定要防超卖。我推荐用带条件的原子更新，而不是先查再改：

from django.db.models import F from django.db import transaction def lock_sku_stock(sku_id, quantity): updated = Sku.objects.filter(pk=sku_id, stock__gte=quantity).update( stock=F('stock') - quantity, locked_stock=F('locked_stock') + quantity, ) if updated == 0: raise ValueError('库存不足，锁定失败')

这里的关键是filter里的stock__gte=quantity条件，UPDATE语句在数据库层面判断库存足够才执行，天然避免并发超卖。如果写成先select再update，两个人同时下单就可能把最后一个库存都买走。

注意：恢复库存时也要用同样的原子更新，千万别用"读出来改完再存回去"的写法。

4. 交易链路实现：购物车、下单和支付回调的闭环

4.1 购物车：匿名会话和登录用户怎么合并

购物车的实现方案有Session和数据库两种。Session的优点是匿名用户可以先用，缺点是无法跨设备；数据库的优点是登录后永久保存，缺点是没登录的用户没有载体。

我的做法是同时支持。CartItem表里user字段和session_key字段都保留，匿名用户购物车挂在session_key上，登录之后把当前session_key下的购物车条目迁移到user名下，再和user名下的旧条目做合并。迁移逻辑里要注意，相同SKU的条目只合并数量，不要产生重复行。

class CartItem(models.Model): user = models.ForeignKey( User, on_delete=models.CASCADE, null=True, blank=True, related_name='cart_items' ) session_key = models.CharField(max_length=64, blank=True, db_index=True) sku = models.ForeignKey(Sku, on_delete=models.CASCADE) quantity = models.PositiveIntegerField(default=1) checked = models.BooleanField('是否勾选', default=True) created_at = models.DateTimeField(auto_now_add=True)

登录转换的逻辑写在登录回调里，做完迁移再跳转。有一个易错点：用户设备上没有session_key但是购物车表里却残留着session数据，这种孤儿数据要定期清理，不然表会无限膨胀。

4.2 下单流程：锁库存和建订单必须在同一个事务里

下单的完整流程我整理成四步：

1. 读取购物车中勾选的商品，校验SKU是否有效、库存是否足够。
2. 生成订单号，计算总价，创建Order主表和OrderItem明细。
3. 在同一个数据库事务里锁定库存，也就是调用前面写的lock_sku_stock。
4. 事务提交后，跳转第三方支付平台发起支付。

这里最核心的原则是"订单"和"库存锁定"必须同生共死，任何一个失败都要整体回滚。

@transaction.atomic def create_order(user, cart_item_ids, address): items = CartItem.objects.select_related('sku').filter( id__in=cart_item_ids, checked=True ) if not items.exists(): raise ValueError('没有选中的商品') order_no = generate_order_no() order = Order.objects.create( order_no=order_no, user=user, total_amount=calculate_total(items), ) for item in items: lock_sku_stock(item.sku_id, item.quantity) OrderItem.objects.create( order=order, sku=item.sku, product_name=item.sku.product.name, sku_name=item.sku.name, price=item.sku.price, quantity=item.quantity, subtotal=item.sku.price * item.quantity, ) items.delete() return order

订单表的关键字段如下，address字段建议直接快照收货人信息，不要关联地址表的主键，否则用户后面改地址会影响历史订单：

class Order(models.Model): STATUS_PENDING_PAYMENT = 1 STATUS_PAID = 2 STATUS_SHIPPED = 3 STATUS_DELIVERED = 4 STATUS_FINISHED = 5 STATUS_CANCELLED = 6 STATUS_REFUNDING = 7 STATUS_REFUNDED = 8 STATUS_CLOSED = 9 order_no = models.CharField('订单号', max_length=32, unique=True) user = models.ForeignKey(User, on_delete=models.PROTECT) status = models.SmallIntegerField('订单状态', choices=..., default=STATUS_PENDING_PAYMENT) total_amount = models.DecimalField('订单总额', max_digits=10, decimal_places=2) receiver_name = models.CharField('收货人', max_length=50) receiver_phone = models.CharField('联系电话', max_length=20) receiver_address = models.CharField('收货地址', max_length=200) payment_no = models.CharField('第三方支付流水号', max_length=64, blank=True) created_at = models.DateTimeField(auto_now_add=True) paid_at = models.DateTimeField(null=True, blank=True)

很多项目会在这一步忘记一件事：下单之后，购物车里的商品应该被清掉，但用户如果中途支付失败，购物车也已经被清了，体验很差。我的处理是，创建订单成功后把已下单的商品从购物车移除，同时在前端提示用户"订单已生成，若未支付可在订单列表继续支付"。

4.3 支付回调：幂等性是资金安全的关键

支付回调是整个交易链路里最容易出资金事故的地方。核心原则是：回调处理函数必须幂等，重复通知和并发通知都不能影响最终结果。

我处理第三方支付平台异步通知的逻辑是：

1. 验签：先用平台公钥验证通知签名，验签失败直接拒绝。
2. 幂等检查：用订单号查出Order，如果订单已经是已支付状态且payment_no一致，直接返回成功，不做任何更新。
3. 加锁更新：在事务中select_for_update锁定订单，把状态改为已支付，记录支付流水号，写入paid_at。
4. 返回成功：通知第三方支付平台"已处理成功"，避免平台反复重推。

@transaction.atomic def handle_payment_notify(order_no, payment_no, amount): order = Order.objects.select_for_update().get(order_no=order_no) if order.status == Order.STATUS_PAID and order.payment_no == payment_no: return True if order.status != Order.STATUS_PENDING_PAYMENT: return False order.status = Order.STATUS_PAID order.payment_no = payment_no order.paid_at = timezone.now() order.save(update_fields=['status', 'payment_no', 'paid_at']) return True

这里的select_for_update保证了两条同时到达的支付通知不会把订单状态更新两次。status判断防止已经取消的订单又被付款成功，这时候要触发退款流程而不是直接发货。我在这个环节还额外加了一个金额校验，回调携带的支付金额必须和订单总额一致，不一致时直接告警并人工复核，这是资金安全的一道重要闸门。

5. 订单状态机与售后设计：从待付款到退款关闭

5.1 订单状态的全量清单和流转规则

订单状态是整个履约过程的中枢。我把这个系统的订单状态整理成了九种：

这里最容易出错的是"已付款"和"已发货"之间的库存语义。我的规则是：付款成功不释放锁定库存，直到发货操作才把locked_stock减掉。这个节奏和财务对账是一致的，发货代表库存真正离开了仓库。

5.2 超时关闭订单的定时任务

待付款订单超过15分钟未支付，系统要自动关闭并把库存返还。这个交给Celery的定时任务处理：

from celery import shared_task from django.utils import timezone from datetime import timedelta @shared_task def close_timeout_orders(): deadline = timezone.now() - timedelta(minutes=15) orders = Order.objects.filter( status=Order.STATUS_PENDING_PAYMENT, created_at__lt=deadline, ) for order in orders: order.cancel_with_stock_restore()

cancel_with_stock_restore方法里要注意并发问题：用户在超时前1秒支付成功，定时任务同时也在跑。所以恢复库存和改状态必须在同一个事务里，而且用select_for_update锁住订单行，先判断当前状态还是待付款才执行关闭。这个细节我一开始没做，测试时就复现了"订单显示已支付但库存被恢复了"的怪现象，排查了很久才发现是定时任务和支付回调撞了车。

5.3 陶瓷易碎：售后模块的隐藏需求

陶瓷品类售后率高，设计退款流程时要预判几种场景：

• 签收前发现破损：通常拒收或即时反馈，物流回传后仓库补发或退款。
• 签收后破损：需要用户提供照片取证，客服确认后走退款。
• 商品描述与实物不符：走退货退款，涉及退货物流跟踪。

退款申请不应该直接改订单状态，我设计了一个独立的售后单模型。售后单和订单是一对多关系，一个订单可以发起多次售后，每次售后单有独立的处理状态。这样订单状态机不会被售后的各种小状态撑爆，而且财务对账时，售后的退款金额可以从售后单维度单独统计，不用去订单表里做复杂的条件聚合。

提示：售后单创建后，如果对应商品已经售罄，系统不要再拦截创建操作，因为陶瓷容易碎，补发可能根本无货可发，要允许售后单记录"无货待换"或"直接退款"的处理结果。

6. 运营后台实战：从Django Admin到批量管理与销售看板

6.1 Django Admin作为起步，针对运营习惯做增强

Django Admin最大的价值是"零成本可用"。我在项目第一天就注册了Product和Sku模型，运营立刻就能录商品。

但直接用默认Admin是不行的，需要针对运营的日常操作做增强。我重点做了四件事：

第一，SKU用TabularInline嵌在Product编辑页里，运营在同一个页面完成"商品信息+所有SKU价格库存"的维护。

class SkuInline(admin.TabularInline): model = Sku extra = 0 fields = ['name', 'sku_code', 'price', 'stock', 'locked_stock', 'is_active', 'sort_order']

第二，给ProductAdmin加上常用的列表筛选和搜索：

@admin.register(Product) class ProductAdmin(admin.ModelAdmin): list_display = ['name', 'category', 'status', 'is_featured', 'stock_status', 'created_at'] list_filter = ['status', 'is_featured', 'category'] search_fields = ['name', 'subtitle'] inlines = [SkuInline]

第三，加批量上架和下架的action，运营选中几十个商品，一键切换状态。

第四，在列表页加一个自定义的库存状态展示列，缺货、库存紧张、正常一眼就能看出。

6.2 批量改价、库存预警与补货提醒

陶瓷行业经常遇到价格调整：窑口涨价了、活动要开始了、尾货要清仓。一个个改SKU会疯掉，所以后台必须支持选一批SKU按比例或固定值调价。

我的实现是一个自定义管理命令加一个后台表单页，运营上传SKU编码和最新价格的Excel，系统批量校验并更新。这一步的坑在于价格字段是DecimalField，Excel里如果填了空格或换行符，解析时要先清洗，否则会报错。

库存预警我做了最简版本：运营后台首页展示一个低库存清单，阈值10件以下标红。别小看这个功能，手工陶瓷补货周期长，提前知道哪些SKU要断货，运营才能尽早协调窑口排期。我在开发时给库存低于阈值的SKU单独做了一个通知位，每个工作日给运营发一封汇总邮件，比让运营自己去翻列表要靠谱得多。

6.3 销售看板：给运营看真正有用的数字

看板我砍掉了大部分炫技图表，只留三个数字：今日销售额、今日订单数、待发货订单量。再加一个近七日热销商品Top10。

from django.db.models import Sum, Count from django.utils import timezone def dashboard_data(): today = timezone.localdate() today_orders = Order.objects.filter(created_at__date=today) return { 'today_sales': today_orders.filter(status__in=[2, 3, 4, 5]).aggregate(s=Sum('total_amount'))['s'] or 0, 'today_order_count': today_orders.count(), 'pending_ship': Order.objects.filter(status=Order.STATUS_PAID).count(), }

运营先靠这几个数字判断今天状态，有异常再下钻看订单列表，比一个花花绿绿的BI页面实用得多。销售统计的日期过滤条件我用的是"支付成功时间"而不是"下单时间"，因为用户下单后不付款的情况很常见，按下单时间统计会把数字灌水，和财务口径对不上。

7. 部署上线与性能优化：开发完成只是第一步

7.1 部署架构：Nginx、Gunicorn与进程守护

上线部署我采用的是经典组合：Nginx + Gunicorn + Django + MySQL + Redis。

gunicorn ceramic_mall.wsgi:application \ --bind 127.0.0.1:8000 \ --workers 3 \ --timeout 60

worker数量不是越多越好，对Django这种有阻塞IO的同步框架，我一般按"CPU核心数乘以2再加1"来起步，然后压测调整。worker太多反而会因为数据库连接数过多把MySQL拖垮。

Nginx负责静态文件、媒体文件和反向代理：

server { listen 80; server_name your-domain.com; client_max_body_size 20m; location /static/ { alias /var/www/ceramic_mall/static/; } location /media/ { alias /var/www/ceramic_mall/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; } }

进程守护我习惯用supervisor，崩溃自动拉起，部署更新时执行reload就好。

7.2 性能优化三板斧：预取、索引、缓存

商城性能问题90%集中在数据库查询。第一板斧是消除N+1查询。商品列表页必须在一次查询里把关联的SKU、分类都带出来：

products = Product.objects.filter(status=Product.Status.ON_SALE).select_related( 'category' ).prefetch_related('skus')

第二板斧是给高频查询字段加索引。订单号、支付流水号、用户ID、订单创建时间、SKU的商品外键这些字段，在列表页和详情页反复被查询，都是明确的索引候选。

第三板斧是页面缓存。商品详情页和列表页可以用cache_page装饰器按URL缓存，加上失效时间。陶瓷商城的商品数据变动频率低，内容页缓存15分钟完全没问题，但要注意：有购物车信息或用户个性化内容的页面不能整页缓存。我在首页和分类页用的是Redis直接缓存渲染后的HTML片段，命中后连Django的模板渲染层都不用进，压测下来QPS提升非常明显。

7.3 媒体文件与图片处理

商品图片是陶瓷商城最重要的资产，直接决定转化率。我建议所有上传图片走Pillow做缩略图，列表页用小图，详情页用大图，减少移动端流量压力。图片格式优先WebP，兼容性不符合要求时回退JPEG。

媒体文件的备份要纳入日常巡检，我由于一开始没做定期备份，某次服务器磁盘故障导致一批商品图丢失，那次的教训非常深刻。现在我的习惯是：数据库每天全量备份，媒体文件每周增量备份，并且备份文件至少保留两份异地副本，千万别让备份和业务数据躺在同一块硬盘上。

我在实际做完这个项目之后，最大的感受是：商城系统的难点从来不在"能不能写出来"，而在"业务变化时，数据模型和状态机扛不扛得住"。陶瓷这个品类把商品离散性、库存非连续性、售后高发这三件事同时摆到你面前，逼着你在设计阶段就把它们一个个想清楚。如果开头图省事套模板，后期每一个"不就是改个状态吗"的需求，都会变成一次伤筋动骨的改动。

最后分享一个小技巧：开发过程中给所有状态字段都预留一个"未知/异常"的枚举值，线上数据一旦出现意料之外的状态，不要急着删记录，先查清楚来龙去脉再处理。电商项目的数据完整性，永远比界面美观重要。