基于Django的农机租赁平台开发：订单状态机与并发控制实战

做农机租赁平台这个项目之前，我在农业信息化方向已经摸爬滚打了几年，但真正让我下定决心用Python把整套收割机租赁系统从零搭起来的，是一次在河南调研时看到的场景：收割季来临，种粮大户在村口蹲着等跨区作业的农机队，而几十公里外几台收割机刚干完活正闲置。两边都有强烈需求，中间就是缺一个靠谱的信息撮合和交易管理平台。这个项目做下来，我最大的感受是：农机租赁听起来像普通电商，但实际建模和交付过程中，档期冲突、作业状态流转、跨区调度这些问题，比想象中麻烦得多。这篇文章我会把这套系统的设计思路、核心代码和踩坑经历完整写出来，给准备做同类系统的人一个可以直接参考的样板。

1. 农机租赁这条赛道，为什么值得用Python重做一遍

1.1 收割机租赁的真实痛点：信息断层比价格更致命

农机租赁不是个新概念，但长期以来整个行业的信息化程度低得惊人。我调研过的租赁场景大概分三类：一是农机合作社内部调度，靠微信群喊话；二是跨区作业服务队，靠熟人介绍和经纪人串联；三是农资经销商兼营租赁，靠手写台账。每一类都有订单管理、机手调度、费用结算的实际需求，但市面上通用的租赁管理系统要么太贵，要么根本不懂农业作业的特殊规则。

这里要特别强调收割机租赁和普通设备租赁的本质区别。普通设备租给客户，客户自己用就行，但收割机租赁通常带机手，作业范围会跨县跨省，一个作业周期可能连续转场好几个地块。这意味着系统不能只管"机器租出去没租出去"，还要管机器在什么时间段在哪块地干活、哪个机手在开、作业进度如何。这些在普通库存系统里都没有对应概念。

1.2 用Python做这套系统的选型逻辑

选Python而不是Java或者PHP，不只是因为Python写起来快。我的核心理由有三个：

• 生态匹配：Django自带的Admin后台、ORM、认证体系非常适合业务管理类系统，农机租赁本质就是一个"信息发布+订单流程+后台管理"的组合，Django开箱即用的部分能覆盖七成需求。
• 数据与可视化：作业面积统计、机手收益排行、农机利用率分析这些都离不开Pandas做数据清洗和Matplotlib/ECharts做可视化，Python技术栈可以无缝衔接，不需要在两种语言之间来回切换。
• 团队成本：农业信息化项目在很多情况下不是大厂做的，而是小团队或个体开发者承接，Python的人才供给量大、上手门槛低，后续别人接手维护也容易。

这也就是为什么我在项目代号上标了hgk9v18j——按我们团队内部规则，每个迭代版本会留一个唯一代号，方便在群里定位问题版本，后面所有踩坑记录都会挂上这个标识。

1.3 技术选型的关键对比

为了给还在纠结的人一个直观参考，我把这次选型时对比过的方案列出来：

我最终确定的技术栈是：Python 3.10 + Django 4.2 + MySQL 5.7 + Redis缓存 + Gunicorn + Nginx，前端用了简单的Bootstrap + jQuery + ECharts，没有上前后端分离。这套组合的好处是单个开发者也能快速跑通全栈，而且交付后客户自己维护起来不费劲。

2. 先把业务模型梳理清楚：三大角色与一条订单主线

2.1 用户端、机主端、管理端各自解决什么问题

农机租赁平台不是简单把设备挂在网上等人下单，它至少涉及三类角色，每类角色的痛点完全不同，技术设计上要分别满足。

• 农户/租户端（需求侧）：核心诉求是"周边有哪些农机可用、价格多少、机手技术怎么样、能不能在我需要的时间段过来"。系统要给这部分用户提供多条件检索、农机详情、在线下单、订单进度跟踪和结算评价能力。
• 农机主/机手端（供给侧）：核心诉求是"我的机器什么时候空闲、谁在租、作业完成后什么时候收到钱"。系统需要提供农机发布、档期管理、接单/拒单、作业状态更新、收益统计等功能。
• 平台管理员侧：核心诉求是"平台上发生了哪些交易、有没有纠纷、农机资质是否合规、整体运营数据如何"。后台需要覆盖审核认证、订单监管、仲裁退款、数据报表等能力。

这三种角色不是简单的权限区别，而是操作逻辑完全不同。我的做法是：在一套Django项目里划分三个App（users、machines、orders），用不同的用户组和权限装饰器做入口隔离，而不是做成三个独立系统。这样用户表只有一张，农机、订单数据天然共享，不会出现多系统之间数据同步的问题。

2.2 订单状态机：从"挂机"到"作业完成"的完整生命周期

订单是本系统的核心实体，也是业务规则最密集的地方。我花了很多时间跟真实的农机手聊，最终把订单状态设计为以下几个：

这个状态机的设计有几个关键考虑：

1. 待支付状态也锁定档期，避免用户下单后又看到同一个时间段被别的用户抢走。但如果超过30分钟不支付，系统自动释放档期——这是通过Django的crontab或Celery定时任务实现的。
2. 支付成功不等于订单生效，需要机主确认。因为农机租赁是重服务场景，机主可能跨区作业中，需要人工确认接单后服务才真正落实。
3. 作业中到结算之间有一个"待结算"状态，因为收割作业的实际面积可能跟预估面积有偏差，最终费用要按照作业面积重新计算，而不是一口价。

这个状态机写出来不算复杂，但后续所有功能——支付回调、订单列表筛选、消息通知、后台仲裁——全部围绕着这一条主线展开。状态机没定义清楚，后面的每个功能都会打架。

3. 数据库设计与Django模型实现：把业务规则落成代码

3.1 核心表结构：用户、农机、订单、档期四张关键表

代码落地之前，必须先设计好数据结构。我在这个项目里没有引入特别复杂的表结构，但有几张表的设计直接影响系统能否正常运转。

第一张是农机信息表（Machinery）。这张表除了基础信息（名称、类型、品牌、型号、出厂年份）以外，有几个农机业务特有的字段必须包含：

• hometown（车辆归属地）——跨区作业的农机通常都有归属地，这关系到能不能接异地订单。
• service_radius（可服务范围，以公里为单位）——大部分收割机只在车辆所在地周边一定区域内作业，超出范围用户搜索时不应展示。
• deposit（押金金额）——农机价值较高，押金是平台的资金安全保障。
• daily_rate和hourly_rate（日租/时租价格）——定价不同，试算逻辑也不同。

第二张是订单表（Order）。订单表的核心不是价格，而是时间段。农机租赁按自然日计算，所以订单需要start_date和end_date两个日期字段。同时为了支持作业面积结算，我加了estimated_area和actual_area两个字段，最终费用按照实际面积计算。

第三张是档期表（Schedule）。这是本系统最关键的防冲突设计。每个农机每一天的可用状态单独成行，字段为machinery、date、status，其中status有available（可租）、locked（已锁定待支付）、booked（已预定）、working（作业中）四种。

第四张是结算表（Settlement），记录押金收取、租金结算、违约金扣除等资金流水。这部分虽然功能简单，但对账的时候非常有用。

3.2 Django模型的关键代码与设计思路

用户表在Django里直接用AbstractUser扩展，加上手机号、用户类型（农户/机主/管理员）、实名认证状态等字段，没什么特别的。

农机模型的核心代码整理如下，有几个细节值得注意：

from django.db import models from django.contrib.auth import get_user_model User = get_user_model() class Machinery(models.Model): CATEGORY_CHOICES = [ ('harvester', '收割机'), ('tractor', '拖拉机'), ('planter', '播种机'), ('drone', '植保无人机'), ] STATUS_CHOICES = [ ('pending', '待审核'), ('online', '已上架'), ('offline', '已下架'), ('disabled', '禁用'), ] owner = models.ForeignKey(User, on_delete=models.CASCADE, related_name='machineries') name = models.CharField('农机名称', max_length=100) category = models.CharField('农机类型', max_length=20, choices=CATEGORY_CHOICES, default='harvester') brand = models.CharField('品牌', max_length=50) model_no = models.CharField('型号', max_length=50) hometown = models.CharField('归属地', max_length=100) service_radius = models.IntegerField('可服务范围(km)', default=50) daily_rate = models.DecimalField('日租价格', max_digits=10, decimal_places=2) deposit = models.DecimalField('押金', max_digits=10, decimal_places=2) cover_image = models.ImageField('封面图', upload_to='machinery/', blank=True) status = models.CharField('上架状态', max_length=20, choices=STATUS_CHOICES, default='pending') created_at = models.DateTimeField(auto_now_add=True) def __str__(self): return f'{self.name}-{self.brand}{self.model_no}'

订单模型是业务核心，代码里用select_for_update做并发控制的部分我会在下一章专门讲。

class Order(models.Model): STATUS_CHOICES = [ ('pending_payment', '待支付'), ('paid', '已支付待确认'), ('confirmed', '已确认待作业'), ('working', '作业中'), ('settled', '待结算'), ('completed', '已完成'), ('cancelled', '已取消'), ] order_no = models.CharField('订单号', max_length=64, unique=True) user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='orders') machinery = models.ForeignKey(Machinery, on_delete=models.CASCADE, related_name='orders') start_date = models.DateField('开始日期') end_date = models.DateField('结束日期') estimated_area = models.DecimalField('预计作业面积(亩)', max_digits=10, decimal_places=2, default=0) actual_area = models.DecimalField('实际作业面积(亩)', max_digits=10, decimal_places=2, default=0) total_amount = models.DecimalField('订单金额', max_digits=12, decimal_places=2, default=0) deposit_amount = models.DecimalField('押金', max_digits=10, decimal_places=2, default=0) status = models.CharField('订单状态', max_length=20, choices=STATUS_CHOICES, default='pending_payment') remark = models.TextField('备注', blank=True) created_at = models.DateTimeField(auto_now_add=True)

订单号我建议不要用自增ID对外展示，生成规则是时间戳+用户ID+随机串，这样订单号不容易被猜测，对账时也能快速解析出时间和来源。

3.3 为什么档期不直接用"订单时间段判断"，要单独建表

很多第一次做租赁系统的开发者会想：判断农机某段时间能不能租，直接查询订单表有没有时间段重叠不就行了？理论上确实可以，但实际会有两个问题。

第一个问题是并发冲突。如果两个用户同时在两台设备上下单，都查询了订单表发现没有重叠，然后同时插入订单记录，数据库就会同时出现两条相同时间段的不同订单——这就是典型的超卖问题。针对这个，可以给订单表加约束，但日期范围重叠很难用唯一约束实现。

第二个问题是待支付锁定的语义表达。用户下单但还没付款的时候，如果直接写进订单表，那么所有查询都要额外判断订单状态，查询逻辑会越来越复杂。单独维护一张档期表，每个租期逐日展开成独立行，状态清晰，查询直观，而且可以给（machinery_id, date）建立唯一索引，从数据库层面杜绝重叠。

所以最终方案就是档期表逐日记录。

class Schedule(models.Model): STATUS_CHOICES = [ ('available', '可租'), ('locked', '已锁定'), ('booked', '已预定'), ('working', '作业中'), ] machinery = models.ForeignKey(Machinery, on_delete=models.CASCADE, related_name='schedules') date = models.DateField('日期') status = models.CharField('状态', max_length=20, choices=STATUS_CHOICES, default='available') class Meta: unique_together = ('machinery', 'date')

这张表的职责只有一个：管理农机在某一天的状态。下单时把订单覆盖日期范围内的所有Schedule行更新为locked；支付后更新为booked；机手点击开始作业后更新为working；订单结束后释放为available。因为unique_together存在，数据库层面就保证了同一台农机同一天只有一行记录，不会因为并发而出现两笔订单共用一天的情况。

4. 搜索、下单与并发控制：三个必须一次做对的核心功能

4.1 多条件组合筛选：地域、时间、类型、价格一个都不能少

农机租赁平台的搜索和普通电商搜索有很大区别。普通电商搜的是"关键词匹配"和"价格区间"，农机租赁多了一个非常关键的维度——作业时间。用户搜索时往往带着明确的时间窗口：我家麦子下周熟，想找10月15日到10月20日能来作业的收割机。

所以搜索接口的设计我采用了Django ORM的Q对象组合查询，核心代码如下：

from django.db.models import Q def search_machineries(request): queryset = Machinery.objects.filter(status='online') keyword = request.GET.get('keyword') category = request.GET.get('category') hometown = request.GET.get('hometown') start_date = request.GET.get('start_date') end_date = request.GET.get('end_date') max_price = request.GET.get('max_price') if keyword: queryset = queryset.filter( Q(name__icontains=keyword) | Q(brand__icontains=keyword) | Q(model_no__icontains=keyword) ) if category: queryset = queryset.filter(category=category) if hometown: queryset = queryset.filter(hometown__icontains=hometown) if max_price: queryset = queryset.filter(daily_rate__lte=max_price) if start_date and end_date: # 查询在指定时间段内，所有日期都处于可租状态的农机 available_machine_ids = ( Schedule.objects .filter(date__range=[start_date, end_date]) .exclude(status__in=['locked', 'booked', 'working']) .values('machinery_id') .annotate(cnt=models.Count('id')) .filter(cnt=(end_date - start_date).days + 1) .values_list('machinery_id', flat=True) ) queryset = queryset.filter(id__in=list(available_machine_ids)) return queryset

这段代码里的核心逻辑是：先查出时间段内所有可用的档期记录，按农机分组计数，如果计数等于时间窗口天数，说明这台农机整个时间段都空闲。我知道这个查询在数据量大的时候效率不算最优，但前期数据量不大时足够用。如果后期农机规模上万台，就要用Redis或者独立的时段索引来替代，不过这是后话，系统先跑起来比过早优化重要。

4.2 并发防冲突：事务加行锁，杜绝"一机两租"

系统上线前我专门做了并发测试：用脚本模拟100个用户同时对同一台农机发起下单，结果出现了让我后背发凉的场景——同一台收割机在某一天被两个用户同时下单成功。这就是时间窗口重叠导致的超卖问题。

解决这个问题不能只靠Schedule表加唯一约束，因为下单流程是"先检查档期，再插入订单，再更新档期表"，三步操作如果不在一个事务里控制并发，中间肯定会出漏洞。正确做法是：在事务里对农机记录加上行锁，让同一个农机的下单请求串行执行。关键代码如下：

from django.db import transaction from django.utils import timezone def create_order(user_id, machinery_id, start_date, end_date, area): with transaction.atomic(): # 对农机记录加行锁，同一台农机同一时刻只有一个请求能走到这里 machinery = Machinery.objects.select_for_update().get(id=machinery_id) # 检查时间段内档期状态 day_counts = end_date - start_date available_days = ( Schedule.objects .filter(machinery=machinery, date__range=[start_date, end_date]) .filter(status='available') .count() ) if available_days != (day_counts.days + 1): raise Exception('该农机在所选时间段内不可租') # 生成订单 days = (end_date - start_date).days + 1 total_amount = machinery.daily_rate * days order = Order.objects.create( order_no=generate_order_no(), user_id=user_id, machinery=machinery, start_date=start_date, end_date=end_date, total_amount=total_amount, deposit_amount=machinery.deposit, status='pending_payment', ) # 锁定档期 Schedule.objects.filter( machinery=machinery, date__range=[start_date, end_date] ).update(status='locked') return order

这里有个细节：select_for_update必须和transaction.atomic()配合使用，事务提交或回滚后锁才会释放。另外要注意MySQL的InnoDB引擎才支持行锁，MyISAM是不支持的。如果你的线上库是别的引擎，这一行代码就起不到并发控制的作用了。

4.3 费用试算：日租价格加押金，还要考虑超时和违约

农机租赁的计费不是简单加个价格字段就完事。我在跟机手聊天时发现，真实业务的费用结构通常包含四部分：日租金、押金、超时费、违约扣除。

我系统的费用试算接口返回给前端的数据结构是这样的：

def calculate_fee(machinery, start_date, end_date): days = (end_date - start_date).days + 1 rent_amount = machinery.daily_rate * days deposit = machinery.deposit return { 'rent_amount': float(rent_amount), 'deposit': float(deposit), 'total_prepay': float(rent_amount + deposit), 'tip': '押金将在订单完成后原路退回' }

超时费和违约扣除在预下单阶段不需要计算，但在结算时要考虑。比如机手完成作业后，用户没有按时归还农机，系统按小时计算超时费；如果用户取消订单时已经进入了确认状态，那么押金中的一部分作为违约金支付给机主。这部分的规则建议在系统内做成可配置项，因为不同地区、不同农机的习惯差异很大，硬编码到代码里后期改起来很痛苦。

5. 开发过程中最棘手的五个问题：每一个都是调试到半夜的血泪

5.1 时区问题：订单时间整整差了8小时

我在开发环境里一切正常，部署到云服务器之后再测试，发现用户下单时间记录总是比客户端时间快了8小时——云服务器默认是UTC时区，而Django的TIME_ZONE配置没有改。这个问题表面上看是小事，但它会直接影响订单催付逻辑：明明用户过了30分钟才付款，系统却判定还没到30分钟，定时任务就不会触发释放锁定的逻辑，档期一直被无效占用。

解决方法是把settings.py里的TIME_ZONE和USE_TZ正确配置：

TIME_ZONE = 'Asia/Shanghai' USE_TZ = True

这里要特别说明：USE_TZ = True时，数据库里存的时间是UTC时区的，Django在读取时会自动转换到TIME_ZONE指定的时区。所以我建议始终开启USE_TZ，不要因为显示时间不对就直接改成USE_TZ = False，这是很多新手容易犯的错误——关闭USE_TZ后系统内部所有时间运算的基准时区会变得混乱，特别是跨天计算时很容易出问题。

5.2 N+1查询：农机列表页从首页开始就卡

系统初期农机数量只有几十台，列表页完全感觉不到问题。等数据量涨到几百台之后，农机列表接口的平均响应时间到了3秒以上。我一开始以为是数据库慢，后来用Django Debug Toolbar一看，原来问题出在ORM的N+1查询上。

列表页每展示一台农机，都要通过owner外键取一次机主姓名，通过cover_image取一次图片URL。页面渲染时循环访问了N次外键，每次外键访问都是一条SQL，几百台农机就产生了几百条SQL查询。

修复方案是查询时主动用select_related把外键关联提前查好：

queryset = Machinery.objects.select_related('owner').filter(status='online')

这个一行代码的改动直接把列表接口从3秒降到了0.4秒。后来我检查了所有列表接口，凡是涉及外键展示的地方都加了select_related，涉及多对多关系的地方用prefetch_related，响应时间整体下降明显。

5.3 图片上传失败与MEDIA路径配置

农机信息发布是机主端的核心功能，上传农机照片时出了个奇怪的bug：本地开发环境图片传得好好的，部署到服务器之后图片就404了。排查了一圈发现，Django的MEDIA_URL和MEDIA_ROOT配置没搞对，上传的文件确实写到了服务器磁盘上，但Nginx没有正确把图片请求指向这个目录。

我的解决办法是在Nginx配置里给media路径追加一个location匹配：

server { listen 80; server_name your-domain.com; location /static/ { alias /var/www/yourproject/static/; } location /media/ { alias /var/www/yourproject/media/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

另外一个容易被忽略的点：Django的ImageField在数据量不稳定的时候，图片会全部堆放在同一个目录里，文件名用默认策略生成，时间长了一台农机的多张照片之间缺乏关联。我建议在模型里自定义upload_to，按农机ID分目录：

def machinery_cover_path(instance, filename): return f'machinery/{instance.owner.id}/{instance.id}/{int(time.time())}_{filename}'

这样后期做图片管理和备份都很方便。

5.4 分页与缓存：列表接口从8秒优化到0.3秒

农机列表页还有一个性能瓶颈是搜索结果都要实时查询数据库，并发量上来后数据库压力非常大。我在第二轮优化时引入了Redis缓存：热门的农机列表、首页推荐等接口加缓存，缓存时间设置为60秒；用户发起下单时主动删除对应接口的缓存，避免拿到脏数据。

缓存代码很简单，用Django自带的cache框架：

from django.core.cache import cache def get_machinery_list(cache_key='machinery_list'): cached_data = cache.get(cache_key) if cached_data: return cached_data queryset = Machinery.objects.select_related('owner').filter(status='online') data = list(queryset) # 序列化逻辑省略 cache.set(cache_key, data, 60) return data

配合分页之后，列表页不管翻到第几页都很快，因为大部分情况下命中的都是缓存。这套方案简单的背后实际反映了大多数中小型系统的真实需求：不要一上来就搞微服务、读写分离、分库分表，先把缓存和索引用好，性能已经能覆盖绝大多数场景。

5.5 数据迁移文件混乱：一个字段丢失引发的线上事故

这是整个项目里最惨痛的教训。有一次我在开发分支改了模型字段，本地执行makemigrations生成了迁移文件，但代码合并到主分支时冲突了，我手动解决冲突后漏掉了其中一个迁移文件。部署后线上直接报数据库字段不存在的错误，整个系统瘫痪了一个小时。

后来我给自己定了几条铁律：

1. 迁移文件必须随代码一起提交，禁止在服务器上直接运行makemigrations，服务器上只用migrate。
2. 模型改动比较多的版本，先在测试环境完整跑一遍migrate再上线。
3. 上线前备份数据库，执行migrate前用python manage.py showmigrations检查未执行的迁移是否与预期一致。

这些东西看起来是普通流程，但真的出事的时候才知道它的价值。特别是在农业项目上线期刚好赶上农忙季节，系统停一个小时就意味着大量订单流失，这种代价宁可多花时间避免。

6. 部署上线与后续扩展：系统真正交付才算开始

6.1 服务器部署的完整链路与踩坑

系统开发完成后部署用的是经典的Gunicorn + Nginx + Supervisor组合。Gunicorn负责跑Django应用，Nginx负责静态文件和反向代理，Supervisor负责守护进程。

部署过程中最值得提醒的是Gunicorn的并发模型配置。使用同步Worker时，每个Worker同时只能处理一个请求，农机列表这种耗时接口很容易把Worker全占满，后续请求全部排队。最简单的优化是把Worker换成gthread模式，并适当增加线程数：

gunicorn yourproject.wsgi:application \ --bind 127.0.0.1:8000 \ --workers 3 \ --threads 4 \ --timeout 120

timeout要特别注意，默认的30秒对上传图片、批量导入数据这种耗时请求来说太短了，我一开始没改，客户端上传了几张高清农机照片就报504。后来改成120秒才稳定。

数据库层面我每天凌晨跑一次自动备份，备份文件保留7天。执行命令可以放到crontab里：

0 2 * * * mysqldump -u username -p password yourdbname > /backup/yourdb_$(date +\%Y\%m\%d).sql

6.2 订单消息通知与农忙季高并发预案

系统稳定运行后，我还做了两件提升体验的事情。第一件是接入短信通知，订单状态在关键节点流转时（下单成功、机主确认、作业开始、完成结算）自动给用户和机手发短信。农业作业场景里很多用户是年纪偏大的种粮户，让他们频繁刷App看状态不现实，短信一条就能解决信息同步问题。

第二件是农忙季的扩容预案。每年5-6月和9-10月是收割机作业高峰，平台流量会比平时高出一个量级倍以上。针对这种情况，我提前把Django的DEBUG关闭，配置了静态文件收集，并且临时增加Gunicorn的Worker数量，数据库连接池也做了扩充。这些操作都不需要改代码，但要在高峰期到来之前准备好，因为临时抱佛脚往往来不及。

6.3 系统后续可以进行的功能扩展

目前这个版本已经能覆盖农机租赁的核心业务流，但离一个真正完整的农业服务平台还有不少路要走。我认为接下来最值得扩展的方向是精准定位与地图调度：把农机的实时位置（通过手机GPS上报）叠加到地图上，用户可以直观看到周边农机的分布和距离。这个功能对跨区作业调度很有价值，每台农机的位置和作业进度透明化之后，农户的信任感会明显提升。

技术上用WebSocket推送位置数据，前端用Leaflet加载地图瓦片，后端保存轨迹数据用于作业面积分析和机手里程统计。这个模块我已经在规划中，如果后续开发完成还会再写一篇单独的文章分享。

最后再分享两个小经验

第一，农机租赁系统虽然挂着"电商"的壳，但核心绝不是支付和商品展示，而是时间段档期管理和线下服务履约。如果你准备动手做，建议先把状态机画清楚，把档期冲突的各种极端情况（跨天订单、连续转场、同机不同机手）想明白，再写代码，否则后面返工的成本非常高。

第二，代码里涉及到钱的逻辑（金额计算、押金退还、违约金扣除）一定要保留完整的操作日志。农机租赁的客单价不低，一旦发生纠纷，平台能提供清晰的订单时间线、金额计算依据和操作记录，很多问题都能快速仲裁，而不是凭感觉判。Django的django-simple-history这个库可以用来记录模型每次修改的历史，我在订单和结算表上都挂了这个记录。

这次的hgk9v18j版本从需求梳理到上线大概花了三周时间，核心代码量不大，但设计上的坑基本都踩了一遍。希望这篇分享能让后来的人少走一些弯路。如果大家在开发过程中遇到类似的问题，欢迎交流讨论。