企业官网建设流程全解析

1. 项目整体设计与方案选型

先说说这个项目是干嘛的。市面上的宠物交易系统不少，但专门围绕乌龟（观赏龟、宠物龟）这个细分品类做交易管理的却不多。做乌龟交易管理系统，核心不是简单搞个商品上架下架，而是要把活体交易的特性吃透：乌龟有品种、大小、健康状况、疫苗驱虫记录、冬眠周期、交易后的运输风险、售后保障周期，这些普通电子商品交易系统根本不替你考虑。Django本身自带Admin后台、ORM、认证权限、模板引擎，正好适合做这种需要快速落地、后台上要管理大量交易单据和健康档案的业务系统。

我当时接到的需求来自一个做龟类养殖和零售的团队，他们之前一直靠Excel和微信群管理订单，问题很明显：龟的品系信息混乱，同一个品种有人叫“巴西龟”、有人叫“红耳龟”，订单状态靠手工改，经常漏单；客户买了龟之后，售后要查这只龟的出生批次、喂养记录，翻聊天记录能翻半小时。所以这个系统的定位很明确：交易管理为主，龟只档案为辅，更重要的是把交易全链路打通——从客户下单、付款登记、发货出库、物流跟踪到售后回访，每一步都能在系统里追溯。

技术选型上为什么用Django而不是其他框架？第一，这个团队需要快速上线，Django的MTV结构清晰，一个开发者在两周内就能做完核心模块，不需要像Spring那样配一堆XML。第二，Django自带Django Admin，像龟只档案维护、品种字典管理这种后台功能，几乎不用写代码就能给运营人员用，省了至少三分之一的工作量。第三，Django的ORM在查交易流水、统计销售额时非常顺手，用.annotate()加Sum()就能出报表，不用额外接BI工具。第四，活体交易系统需要有严格的权限控制，Django的用户认证与权限组是内置的，虽然默认的可能不够细，但扩展起来不费劲。

注意，这里我说的“交易管理系统”，不是花里胡哨的高并发电商平台。它更像一个“内外部协同的订单管理系统”：外部客户能看到商品和下单，内部员工处理订单、管理龟只库存、登记财务。所以架构上没必要用微服务，一个Django项目加上PostgreSQL足够，再加个Redis做缓存和会话存储就已经很稳了。

整体模块划分我按照业务链路来，不按传统Web框架的Model/View分：

• 龟只档案模块：管理每一只龟的唯一编号、品种、性别、体长体重、年龄、健康状况、检疫记录、所在场地（种龟区/育苗区/销售区）。
• 交易订单模块：客户的购买订单，包含下单、支付登记、发货、签收、完成、售后的全状态流转。
• 客户管理模块：客户信息、会员等级、收货地址、历史购买记录。
• 库存与批次模块：按批次管理龟只，每次入库/出库影响对应批次的余量。
• 回访与售后模块：记录客户反馈、死亡补偿、退换货处理。
• 统计报表模块：销售排行榜、品种热度、月销售额、库存预警。

架构上就是典型的Django单体应用：turtles（档案）、orders（订单）、customers（客户）、inventory（库存）、reports（统计）这几个App。

2. 数据库建模与关键表结构设计

2.1 龟只档案表：活体管理的基础

建模时最容易踩的坑，就是把龟当“普通商品”来设计。一只龟不是一个SKU，它是有生命、有状态的个体。我见过不少人把“乌龟”直接映射成一个name字段加一个price字段，然后发现卖出去之后库存没法自动减——因为活体不可能无限上架，每一只都是独特的。所以我把龟只设计成Turtle模型，每个实例对应一只具体的龟。

class Turtle(models.Model): GENDER_CHOICES = [ ('M', '公'), ('F', '母'), ('U', '未知'), ] code = models.CharField('唯一编号', max_length=32, unique=True) breed = models.ForeignKey('Breed', on_delete=models.PROTECT, verbose_name='品种') gender = models.CharField('性别', max_length=1, choices=GENDER_CHOICES, default='U') birth_date = models.DateField('出生日期', null=True, blank=True) weight = models.DecimalField('体重(g)', max_digits=8, decimal_places=2, default=0) length = models.DecimalField('背甲长(cm)', max_digits=5, decimal_places=1, null=True, blank=True) status = models.CharField('状态', max_length=16, choices=[ ('IN_STOCK', '在库'), ('RESERVED', '已预定'), ('SOLD', '已售出'), ('RETURNED', '退货中'), ('DEAD', '死亡'), ], default='IN_STOCK') health_report = models.TextField('健康记录', blank=True) batch = models.ForeignKey('Batch', on_delete=models.PROTECT, verbose_name='入栏批次') created_at = models.DateTimeField('创建时间', auto_now_add=True)

code字段是龟只的唯一编号。这里的编号不是随便填的，我建议遵循业务规则生成，比如BR-M-2024-0001表示“巴西龟-母-2024年批次第1只”，这样线下扫码、线下核对都方便。status字段是核心，所有交易操作本质上就是改这个状态。breed用外键关联到Breed字典表，避免不同员工录“草龟”和“中华草龟”导致数据不一致。

2.2 订单表与状态机设计

订单表要支持交易全流程，但不能做成一张“大宽表”。原本想每个订单存一个current_status字符串就完了，实际操作下来会发现：状态流转的历史记录非常重要。比如客户说“我的龟怎么还没发”，你一看订单是“已付款”，但不知道是哪个环节卡住了；如果只有当前状态，根本查不到什么时候付的款、什么时候审核的。所以我加了OrderStatusLog表来记录每一次状态变更。

class Order(models.Model): order_no = models.CharField('订单号', max_length=32, unique=True) customer = models.ForeignKey(Customer, on_delete=models.PROTECT) total_amount = models.DecimalField('总金额', max_digits=12, decimal_places=2) status = models.CharField('订单状态', max_length=16, choices=[ ('PENDING_PAYMENT', '待付款'), ('PAID', '已付款'), ('AUDITING', '审核中'), ('SHIPPED', '已发货'), ('COMPLETED', '已完成'), ('REFUNDING', '退款中'), ('REFUNDED', '已退款'), ], default='PENDING_PAYMENT') shipping_address = models.CharField('收货地址', max_length=255) remark = models.TextField('备注', blank=True) created_at = models.DateTimeField('下单时间', auto_now_add=True) paid_at = models.DateTimeField('付款时间', null=True, blank=True) shipped_at = models.DateTimeField('发货时间', null=True, blank=True) class OrderItem(models.Model): order = models.ForeignKey(Order, related_name='items', on_delete=models.CASCADE) turtle = models.ForeignKey(Turtle, on_delete=models.PROTECT) price = models.DecimalField('成交单价', max_digits=10, decimal_places=2) quantity = models.PositiveSmallIntegerField('数量', default=1)

订单金额其实应该由OrderItem的price * quantity计算得出，为了避免每次循环查数据库，我直接冗余了total_amount字段，通过表单保存时统一计算。订单状态机我用Django的FSMField或者自己写状态校验？实际项目里没有引入额外依赖，直接用了choices加clean()校验。

2.3 库存批次与字典表

除了龟只个体表，我还设计了Batch（批次）概念。为什么需要批次？一个养殖场可能同一批孵化的龟，基因来源、喂养饲料、疫苗驱虫时间都一样，如果一只一只录，维护成本太高。批次表存了入栏日期、来源（自繁/外购）、初始数量、剩余数量。Turtle表通过外键关联到批次。库存统计可以按批次聚合：某个品种当前在库多少只，就是Turtle.objects.filter(breed=..., status='IN_STOCK').count()。

品种字典表和场地表也很重要。品种表不能只有名字，还要有生长适温、性格特点、是否保护动物等属性；场地表用于区分种龟室、育苗室、销售展示区，方便后续扩展养殖管理功能。

2.4 客户表与会员等级

客户表设计了三块：基本信息、联系信息、交易偏好。交易偏好里我加了一个prefer_breed字段，方便后续做营销推荐。会员等级可简单用level字段实现：0普通、1白银、2黄金、3钻石。等级变化靠累计消费金额触发，在订单完成时更新客户累计金额，这个方法简单但很实用。

设计表结构时，我强烈建议所有涉及钱和龟只状态的字段都加约束。比如price必须大于0，quantity不能为负数。Django的CheckConstraint在迁移时会生成数据库约束，能挡住不少脏数据。

3. 核心交易流程的实现细节

3.1 下单与库存预占：避免超卖

活体交易和普通电商一个很大的不同，是库存不可能补货补得很快，一只龟就一只，卖完就没了。所以下单环节必须做“库存预占”：客户加入购物车时先不锁，但提交订单时要把对应的龟只状态从IN_STOCK改成RESERVED。如果在超时时间内未支付，解除预定；如果支付成功，置为SOLD。

为了安全起见，预占操作要用事务包裹。我用Django的transaction.atomic()，并且在修改状态时加select_for_update()锁行，防止两个客户同时买同一只龟。

from django.db import transaction @transaction.atomic def reserve_turtle(turtle_id, order_no): turtle = Turtle.objects.select_for_update().filter(id=turtle_id, status='IN_STOCK').first() if not turtle: raise ValueError('该龟只不在可售状态，可能已被其他客户预订') turtle.status = 'RESERVED' turtle.save() # 关联订单项的创建逻辑...

这里有个细节，select_for_update()必须用在事务里，而且如果数据库是SQLite，行锁不生效，所以生产环境一定要用PostgreSQL或MySQL。开发的时候用SQLite测试没事，但别以为线上也安全。

购物车那张表我其实没做成数据库表，而是存在Redis里，键为cart:{user_id}，值为一个包含龟只ID和数量的Hash。为什么不用数据库？购物车是临时数据，Redis天然支持过期时间，存数据库还要做清理任务。Django里操作也简单，用redis-py就行。

3.2 支付登记：不接真实支付，模拟回调

因为这是一个内部管理为主的项目，没有直接接支付宝微信支付，而是做了“支付登记”功能：订单在PENDING_PAYMENT状态时，运营后台会看到线下转账凭证图片和金额，审核员确认到账后点“确认收款”，订单变成PAID并记录paid_at。

如果以后要接真实在线支付，可以把支付平台抽象成接口。实际代码里我定义了一个通用的PaymentProvider接口，里面只有create_payment(order)和handle_callback(payload)两个方法，后续接支付平台只需要实现这两个方法，不需要改订单逻辑，麻烦的只是回调验签。

3.3 发货与物流：把龟只关联到物流单

乌龟是活物，发货流程比普通商品多好几步：打包前要检查健康状态、准备专用的运输箱和保温材料、在系统里填写物流单号和运输方式（陆运/空运/快递），还要设置预计到达时段。我设计了一个Shipment模型：

class Shipment(models.Model): order = models.ForeignKey(Order, related_name='shipments', on_delete=models.PROTECT) shipment_no = models.CharField('物流单号', max_length=64) carrier = models.CharField('承运商', max_length=32) # 例如某快递、某物流 method = models.CharField('运输方式', max_length=16, choices=[('LAND', '陆运'), ('AIR', '空运')]) packed_at = models.DateTimeField('打包时间', null=True, blank=True) shipped_at = models.DateTimeField('实际发货时间', null=True, blank=True)

订单状态变为SHIPPED后，页面会展示物流单号，同时客户账户中心能查看。这里有一个细节：一单可能分多次发货，比如客户买了两只龟，一只要检疫隔离两周，另一只当天能发。所以我用一对多的Shipment外键，而不是在订单表上只留一个物流单号字段。

3.4 售后与回访：交易闭环的最后一步

活体交易最大的痛点是售后。龟在运输途中可能应激、生病甚至死亡。系统需要支持“售后退款登记”和“死亡理赔”流程。我实现的方式是给订单增加售后标记，新建AfterSale表，包含类型（退款/补发/部分补偿）、原因、处理人、处理结果、图片凭证。客户在移动端申请，后台审核。

回访记录独立建表，关联订单和客户，记录回访日期、回访内容、客户反馈。这看起来简单，但非常实用：运营团队每月可以统计回访率，也能在客户反馈中挖掘品种质量问题。

4. 后端视图与接口设计实战

4.1 用Django Class-Based View组织页面逻辑

我写Django项目更倾向于用CreateView、UpdateView这些类视图，因为CRUD场景太多了，能少写一半样板代码。以订单创建为例，直接继承CreateView，指定模型和表单，再重写form_valid方法做库存预占。

class OrderCreateView(LoginRequiredMixin, CreateView): model = Order form_class = OrderCreateForm template_name = 'orders/order_create.html' def form_valid(self, form): try: with transaction.atomic(): response = super().form_valid(form) self.object.order_no = generate_order_no(self.object.id) self.object.total_amount = self.object.items.aggregate( total=Sum(F('price') * F('quantity')) )['total'] or Decimal('0.00') self.object.save() # 遍历订单项，预占龟只 for item in self.object.items.select_related('turtle'): reserve_turtle(item.turtle_id, self.object.order_no) return response except ValueError as e: form.add_error(None, str(e)) return self.form_invalid(form)

很多人不习惯在form_valid里做太多事，但我这里业务必须绑定，不然库存预占不成功订单就没法创建。你可以在Service层做，但小型项目没必要过度设计。

4.2 前端页面与Django模板

模板用的是Django自带模板引擎+Bootstrap 5，没有上前后端分离。虽然不是特别现代，但团队内部系统够用。模板继承写了base.html，把导航栏、消息提示、权限判断都放进去。关键列表页用DataTables做分页和搜索，表格加载快，不需要写复杂前端。

这里想提醒一点：Django模板中访问外键字段很容易出现“N+1查询”问题。比如订单列表页，要显示每只龟的品种，你写order.items.all循环，每循环一次就要查一次品种。解决方法是使用prefetch_related：

orders = Order.objects.prefetch_related( 'items__turtle__breed', 'customer', ).filter(status=selected_status)

用了prefetch_related之后，SQL查询次数从N+1降到了固定几次。

4.3 DRF接口：给移动端或小程序准备

虽然核心后台是服务端渲染，但客户想在小程序上查看订单怎么办？我建议还是把对外接口用Django REST Framework（DRF）提供。我做了一套只读+下单的轻量接口：GET /api/turtles/（在售列表）、GET /api/orders/（客户本人订单）、POST /api/orders/（创建订单）。鉴权用rest_framework_simplejwt，客户小程序端登录后拿到JWT Token。

DRF的序列化器里，有个很实用的技巧：列表接口只返回龟只基本信息，详情接口返回所有健康记录，使用不同的Serializer。

class TurtleListSerializer(serializers.ModelSerializer): breed_name = serializers.CharField(source='breed.name') class Meta: model = Turtle fields = ['id', 'code', 'breed_name', 'weight', 'length', 'price'] class TurtleDetailSerializer(TurtleListSerializer): class Meta(TurtleListSerializer.Meta): fields = TurtleListSerializer.Meta.fields + ['health_report', 'batch_info', 'status']

这样列表页和详情页的响应数据大小完全不同，页面加载更快。

5. 权限控制与安全管理

5.1 角色权限设计：不是所有人都能改订单

后台使用者有三类角色：客服、运营、管理员。客服可以创建订单、登记发货、录入回访；运营可以管理龟只档案、查看报表、处理退款；管理员啥都能干。Django自带的Group和Permission能满足大部分需求，我给每个模型都配置了view/add/change/delete权限，然后组里勾选。

注意一个坑：Django默认的权限粒度是模型级的，但如果想限制“客服只能查看自己创建的订单”，这就要在视图里做额外判断。我使用了get_queryset重写：

class OrderListView(LoginRequiredMixin, PermissionRequiredMixin, ListView): permission_required = 'orders.view_order' def get_queryset(self): qs = super().get_queryset() if self.request.user.groups.filter(name='客服').exists(): qs = qs.filter(creator=self.request.user) return qs

权限控制如果做得太细，维护成本剧增，运营团队沟通成本也高。我的原则是“岗位级粗粒度+关键操作留痕”，客服能看所有订单但改不了价格，价格修改需要运营权限，这个通过表单字段权限控制实现。

5.2 登录安全与操作审计

Django自带的LoginView配置好LOGIN_URL就能用，但生产环境建议强制启用HTTPS、配置安全Cookie（SESSION_COOKIE_SECURE=True、CSRF_COOKIE_SECURE=True）。登录尝试还可以加django-axes插件，连续几次失败就锁定账号。

操作审计我用了两个方案：Django Admin的LogEntry只记录Admin后台操作，业务前台的自定义操作（如改价、退款、修改订单状态）单独加到OperationLog表里。核心是记录“谁在什么时间对哪个订单做了什么操作”，方便客服和客户扯皮的时候查证据。

5.3 文件上传与安全

售后凭证、龟只照片使用ImageField上传。这里有几个很实际的安全配置：

• MEDIA_ROOT和MEDIA_URL分开，且Nginx里配置只允许指定扩展名。
• 上传大小限制在5M以内，通过FILE_UPLOAD_MAX_MEMORY_SIZE和前端校验双重控制。
• 存储文件名不要用原名，用uuid4().hex + 后缀，避免路径穿越和重名覆盖。

6. 统计报表与数据可视化

6.1 常用统计查询：用ORM完成日报月报

日常运营最关心的几个数字：当日订单数、销售额、龟只销量、待发货订单数、库存预警。 Django ORM配合annotate可以很快算出来。比如统计过去30天每个品种的销量：

from django.db.models.functions import TruncDate from django.db.models import Sum, Count daily_sales = (OrderItem.objects .filter(order__status='COMPLETED', order__paid_at__gte=start_date) .annotate(day=TruncDate('order__paid_at')) .values('day', 'turtle__breed__name') .annotate(total_qty=Sum('quantity'), total_amount=Sum('price')) .order_by('day'))

这个查询结果是一个字典列表，直接传给前端表格或图表库都行。数据量大以后加索引，索引组合建议是(order__paid_at, turtle__breed__name)，如果没有还想再加prefetch_related优化连接查询。

6.2 展示层：用简单图表而非重型BI

我的经验是，内部系统不要一上来就上大而全的报表系统，先用ECharts或Chart.js画几个核心图表就够。我在模板中直接引了Chart.js，后端把统计数据渲染为chart_labels和chart_values两个JSON数组，前端一行new Chart(ctx, {...})搞定。不需要写接口，也不用维护前端工程。

库存预警我做成一个列表视图，查询条件就是Turtle.objects.filter(status='IN_STOCK').values('breed').annotate(count=Count('id')).filter(count__lte=F('breed__stock_warning'))。每个品种设置了stock_warning阈值，低于阈值就会在预警页面高亮显示。

7. 部署上线与性能优化

7.1 生产环境架构选型

开发环境每个人本地跑SQLite就行，但生产环境必须换PostgreSQL。Django的ORM在PostgreSQL下能用的特性更多，比如select_for_update行锁、JSONField全文搜索。 Web服务器我用Gunicorn跑Django应用，前面加Nginx做静态文件服务和反向代理。静态文件和用户上传的媒体文件都放在Nginx可访问的目录，Django的collectstatic负责收集。

Redis用作了两个用途：缓存（Django Cache）和购物车存储。Cache配置我用django-redis：

CACHES = { "default": { "BACKEND": "django_redis.cache.RedisCache", "LOCATION": "redis://127.0.0.1:6379/1", "OPTIONS": {"CLIENT_CLASS": "django_redis.client.DefaultClient"} } }

7.2 部署脚本与Docker Compose

为了方便部署，我写了一个docker-compose.yml，包含Django应用、PostgreSQL、Redis这三个服务。Django镜像可以用Python 3.11-slim基础镜像，安装依赖后启动Gunicorn。

version: '3.8' services: db: image: postgres:15 environment: POSTGRES_DB: turtle_db POSTGRES_USER: turtle_user POSTGRES_PASSWORD: secure_password volumes: - pgdata:/var/lib/postgresql/data redis: image: redis:7-alpine web: build: . command: gunicorn turtle_system.wsgi:application --bind 0.0.0.0:8000 --workers 3 volumes: - static_volume:/app/static - media_volume:/app/media depends_on: - db - redis environment: DJANGO_SETTINGS_MODULE: turtle_system.settings_production ports: - "8000:8000" volumes: pgdata: static_volume: media_volume:

部署时，数据库迁移记得用python manage.py migrate，收集静态文件用python manage.py collectstatic --noinput。我这个项目里写了个entrypoint.sh来先跑迁移再启动Gunicorn，避免每次忘了迁移。

7.3 性能优化与缓存策略

第一，查询层面，凡是列表页都尽量用select_related和prefetch_related，避免N+1。第二，热点页面做缓存，比如龟只列表页缓存5分钟，缓存键是turtle_list_page_{页码}，后台更新龟只时主动删掉缓存。第三，静态文件交给Nginx，Django只处理动态请求。

实际运行中，我发现一个容易被忽视的性能点：当龟只档案达到上万条，后台的龟只下拉框加载很慢。解决方案是用Django Admin的autocomplete_fields，通过SearchView自动搜索来实现，而不是一次性全量渲染。

8. 常见问题与排查技巧实录

8.1 问：为什么select_for_update在SQLite下不管用？

这是我在开发环境踩过的坑。SQLite不支持行级锁，它只有数据库级写锁，所以在SQLite里select_for_update()会被Django忽略。 我用它做库存预占的本地测试时发现，开两个终端同时提交订单，居然都成功了，互不阻塞。后来查文档才知道SQLite不支持这个特性。正式环境换成PostgreSQL后问题解决。如果你的项目暂时只能用SQLite，别依赖行锁，可以用transaction.atomic()加更新条件的方式：UPDATE语句本身带原子性，比如Turtle.objects.filter(id=turtle_id, status='IN_STOCK').update(status='RESERVED')，返回值是影响行数，为0就说明没抢到。这种方式比行锁更简单，也不依赖数据库类型。

8.2 问：订单状态流转如何防止误操作？

我只在业务层做了状态合法性的简单校验，没有引入状态机库。比如“已发货”的订单不能直接变成“待付款”。方法是状态字段的choices只是展示，真正校验放在保存表单时的clean()里：

def clean_status(self): new_status = self.cleaned_data.get('status') old_status = self.instance.status if self.instance else None allowed_transitions = { 'PENDING_PAYMENT': ['PAID', 'REFUNDED', 'CANCELED'], 'PAID': ['AUDITING', 'SHIPPED', 'REFUNDING'], 'SHIPPED': ['COMPLETED', 'REFUNDING'], } if old_status and new_status not in allowed_transitions.get(old_status, []): raise ValidationError(f'订单状态不允许从{old_status}变更为{new_status}') return new_status

这个方法有效防止了运营人员手滑改错状态，但有个前提：所有修改状态的入口都要用这个表单校验，不能绕过表单直接写Order.objects.filter(id=...).update(status=...)。建议预警一下团队成员，统一用save()方法。实际业务里，人工审核的环节很容易出现状态跳变，比如客户未付款就想取消，但后台人员可能直接改成了退款，这个靠状态机限制能拦住一部分。

8.3 问：龟只档案录入太繁琐，怎么能提高效率？

我做了两个优化。第一，支持CSV批量导入，运营人员将从Excel整理好的龟只数据直接导入，字段映射在导入页面选择。第二，批量操作：在列表页勾选多只龟，可以一键改状态为“已预定”或“已售出”。用Django Admin的actions功能即可实现。批量导入一定要先做数据校验，模板放在turtle_system/utils/import_turtles.py里，导入前预览异常行，导错时回滚整个事务，不然会创造出很多脏数据。

8.4 问：上传的龟只照片太大，页面加载卡顿怎么办？

这个问题很现实。Django默认的ImageField在上传时会直接保存原图，几十张几MB的图片会导致列表页越来越慢。我的方案分两步：一是上传时用Pillow库生成两种尺寸的缩略图（列表用小图，详情用原图），并把缩略图路径存到ImageField里；二是Nginx开启静态资源缓存，让浏览器直接命中本地缓存。如果对图片清晰度要求高，可以用django-imagekit这个库，它在ImageSpecField里处理缩略图更优雅，不污染原字段。

8.5 问：统计报表一直查出重复数据？

这个坑主要在QuerySet的values().annotate()组合上。比如统计每个品种的销量，如果先.values('turtle__breed')再.annotate(Sum('quantity'))，会出现每个品种多行结果，原因是Django的GROUP BY字段没包含品种的名字，而只包含ID。解决方法是.values('turtle__breed__name')，保证分组字段和你需要展示的字段完全一致。如果还不够，检查是否有多个OrderItem关联到同一只龟但在不同订单里，要考虑过滤订单状态。我建议每次写完统计查询后，用print(qs.query)看下SQL是否如预期。

9. 我的几点实操体会与后续扩展建议

做完这个项目，最大的体会是：Django最舒服的地方不是“快”，而是“稳”。你不用反复确认用户认证、CSRF、ORM连接池这些基础设施，可以把精力全放在业务逻辑上。当然，代价是如果你一开始没把模型设计好，后面改起来比较痛苦。比如我最初把“批次”直接嵌套进龟只表，后来要按批次统计进货成本时，发现连Batch外键都没有，不得不加班补了一个模型并迁移数据。所以做这类管理系统，第一步千万别急着写代码，先在纸上画清楚对象关系和状态流转，比什么都重要。

另外，活体交易和普通商品交易的差别，值得每个做类似系统的人仔细想：你的“库存扣减”应该发生在哪个环节？茧站的东西下单就扣库存，但龟只这种非标品，应该是“支付才扣”，因为客户可能被别人先预定，你必须在下单时锁单。我最终的策略是“下单预占、超时释放、支付锁定、发货出库”，四步状态关系在代码里注释得清清楚楚，团队后续也好维护。

这个系统后续要扩展的话，我觉得有两个方向比较有价值：一个是接入真实电子支付，同时自动生成财务流水对账表；另一个是增加简单的RFID或二维码追溯，把每一只龟从出生到销售的全生命档案给客户看。后者对提高复购率和品牌信任度的帮助非常明显。技术都不难，Django生态里都有现成方案，关键看业务怎么用。

如果你也要做类似的交易管理系统，记住一句话：先解决好“状态一致性”和“数据可追溯”，再谈界面美观和功能丰富。需求排期时这两项必须排在工时前面，否则等你在线上线后，光是处理订单状态混乱和客户客诉就能拖垮整个项目。