这个项目前后折腾了一个多月从最初的需求梳理到小程序真机跑通整个“找车-下单-支付-取车-还车”闭环中间踩了不少坑。写这篇博客的时候我尽量把技术方案和决策过程都还原出来包括为什么选 PythonDjango、数据表为什么那样设计、订单状态机怎么转以及部署上线时那些容易让人卡壳的细节。如果你正在做类似的自驾游租车小程序或者准备用 Django 给小程序做后端这篇文章应该能让你少走一些弯路。1. 项目定位与整体技术选型1.1 这个项目到底解决什么问题自驾游租车和传统到店租车最大的区别在于用户不会乖乖守在门店里办手续。他们可能在机场刚落地可能住在景区附近的民宿里想临时租一辆车跑个两三天还车点也可能和取车点不在同一个城市。所以这个产品要解决的三个核心问题非常明确随时随地浏览车辆、线上下单支付、无接触式取还车。围绕这个定位整个项目最终做成了“手机小程序 后台接口 管理后台”三件套。用户通过小程序完成身份认证、车辆选择、订单创建、租金和押金支付、地图找车、扫码取还车管理后台则处理车辆上下架、订单审核、结算异常、优惠券发放这类偏运营的操作。小程序端不用下载安装扫码即用对临时场景特别友好这也是业务方坚持要做小程序而不是 App 的核心原因。我这边负责的是整个后端接口设计和大部分小程序端业务逻辑。前端原生能力调用比较多比如地图定位、微信支付、图片上传所以小程序端没有用跨端框架直接用了原生语法代码结构上也更容易维护。1.2 为什么是 PythonDjango小程序这个组合技术选型的时候我和团队内部其实讨论过好几版方案。第一版想过纯小程序云开发不用管服务器数据库、存储、云函数一条龙。当时差点就定了但仔细核对需求后发现租车业务后续要接车辆 GPS 定位、违章查询、对接第三方支付对账这类偏重业务逻辑和对外接口的功能云开发的表达力还是弱一些而且换服务商就要重构太被动。第二版考虑过 Node.jsExpress前后端语言都是 JavaScript理论上可以共用类型定义。但团队之前用 Django 写过管理后台类的系统对 ORM、Admin、迁移体系都很熟再引入一套新语言栈的维护成本反而不划算。最后就定了 PythonDjango。Python 这边选 Django原因很朴素自带的后台管理模块能让我在项目第三天就做出一个给运营用的车辆管理界面不用单独写 CRUDDjango ORM 做订单、押金这类强关联查询非常顺手Django REST Framework 生态成熟序列化、权限、分页这些高频需求都有现成组件。小程序端选原生语法主要是为了稳。跨端框架在原生 API 的暴露上总有一些延迟而地图、支付、选择器这类功能恰恰是小程序租车场景的核心我不太想在框架兼容性上花时间。实战下来这个决定是值得的原生 page 写起来并不慢而且编译体积小。1.3 整体架构与请求链路整个系统跑起来之后大致是这样一条链路用户在小程序端授权登录后端用微信的 code 换 session_key再签发自己的 JWT用户浏览车辆、填写取还车时间后端根据时间计算预估价提交订单后端使用事务创建订单一并写入支付凭证表调用微信支付统一下单接口拿到支付参数小程序端调起支付支付成功回调后后端更新订单状态押金默认冻结在支付环节里微信分账方案如果没开通就先在业务库记录押金状态用户到取车点扫描车辆二维码后端校验时间窗和订单有效性完成取车还车前上传车辆照片后端生成结算单多退少补推送到用户端确认。部署上使用 Nginx 托管静态文件反向代理到 GunicornMySQL 存储业务数据Redis 缓存车辆可约状态和用户登录态。小程序端最终有专门的合法域名HTTPS 证书配齐后才能上线。2. 数据模型设计不只建表还要把业务规则织进去2.1 核心表结构与字段考量租车业务数据模型说复杂也复杂说简单也简单。我整理下来核心就四类车辆、门店、订单、用户。但每张表的字段都需要把业务规则塞进去否则后面写接口会很难受。车辆表最重要的字段除了品牌、车型、座位数、变速箱类型、能源类型这些展示字段外还有几个容易被忽略的车牌号做了唯一约束同一辆车不允许被录入两次这个看似基础但运营经常会手动录错车辆状态字段不是简单的布尔值分别有可用、已预约、使用中、维修中、已下架这和库存强关联车况描述和车辆照片分开存照片用多图 JSON 列表字段方便前端轮播展示日租金、押金、超时小时费率、里程费方案用数字精度字段存价格场景一律不用浮点数避免精度丢失问题。订单表比车辆表复杂它承担了租车流程最核心的状态流转。我把订单表拆成了“订单主表 结算扩展表”主表存基础信息扩展表存费用明细。这样做的原因是租车订单的完整结算往往在还车时才确定提前把所有字段塞进同一张表会很臃肿。订单表关键字段字段类型说明order_no字符串唯一业务订单号规则日期随机串user外键用户vehicle外键车辆store_take / store_return外键取车/还车门店支持异地还车start_time / end_time时间字段预计取车/还车时间actual_start / actual_end时间字段实际取还车时间rental_fee数字基础租金deposit数字押金status字符串索引当前状态cancel_reason文本取消原因运营审核时参考用户表我单独建了 user_profile 表和微信登录用户一对一关联存身份证、驾驶证信息、实名状态。需要注意驾驶证信息涉及个人隐私数据库里做了加密存储接口只返回“已认证/未认证”这种状态不做明文回传。2.2 订单状态机设计订单状态机是整个项目里我思考最多的地方。租车不是一个“支付成功就完了”的业务它会经历多个中间状态每个状态之间的跳转条件也很多。我把订单状态定义成了这样一串待支付PENDING_PAY用户提交订单后初始状态已支付/待取车PAID支付成功等待用户取车使用中IN_USE用户扫码取车成功待结算PENDING_SETTLE用户提交还车等待费用确认已完成COMPLETED结算确认订单关闭已取消CANCELLED用户主动取消或超时未支付自动取消异常ABNORMAL还车超时未处理或者结算争议需要人工介入。实现状态机时我直接在 Django Model 层面维护了一个状态字段并写了一个transition()方法统一做状态转移校验每次转移必须满足前置条件否则抛异常。这个方法会比在视图层到处写 if 判断可靠得多因为状态转移的逻辑被集中在一个地方测试也好写。比如“待支付到已支付”只能由支付回调触发且回调金额必须等于订单金额“使用中到待结算”必须由用户点击还车且车辆照片上传完成触发“使用中到异常”由定时任务扫描发现超时用车而触发。2.3 计费与押金字段为什么这么设计租车计费并不像看起来那么简单。基础逻辑是日租金乘以租期但租期不是简单算天数差而是按小时粒度折算。我当时定的规则是租期不足 4 小时的按半天计费超过 4 小时不足 24 小时按全天计费超时还车按小时费率额外计费。这个规则不能用 Django DecimalField 搞简单加减乘除需要写一个独立的计费模块。计费模块我用 Python 的datetime做时间差计算再对分钟数做向上取整处理。举例来说用户取车时间是 2024-06-01 10:00还车时间是 2024-06-03 14:30时间差是 52.5 小时按规则折算下来是两天又 4.5 小时租金等于日租金乘以 2 再加上半天费率。如果取还车时间和预计时间不一致按取消梯度扣没退的租金以及超时费都是在这个模块里统一算的。押金的处理前期因为业务方没开通微信支付的“分账”能力我采用的方式是用户在支付租金时同时支付押金押金记录在订单的 deposit 字段里还车结算确认后原路退回。这个方案实现简单但弊端是用户需要先冻结一笔钱在小程序账户里体验稍差。后来如果有条件可以改用微信支付的分账能力把押金做成平台冻结资金本质上还是靠微信支付提供的商户能力支撑。关于金额存储我全部用了 Django 的DecimalField(max_digits10, decimal_places2)在代码里所有涉及金额的运算统一用Decimal类型禁止直接使用 Python 浮点数做价格计算。这里吃过一次教训早期用浮点算超时费出现过 0.30000000000000004 这种结果哪怕只差一分钱用户投诉起来都非常麻烦。3. 后端接口与关键功能实现3.1 小程序登录鉴权链路小程序登录和后端 JWT 的结合是这个项目第一个要打通的环节。小程序端wx.login()拿到临时 code传给后端接口后端拿着 code 去微信接口换 openid 和 session_key然后在自己的数据库里找或者创建用户记录最后签一个 JWT 返回给小程序端。Django REST Framework 里我用了django-rest-framework-simplejwt做 JWT 签发和校验。一部分人会把 JWT 和微信绑定流程混在一起导致逻辑混乱。这里我建议把它们拆开微信 code 换 openid 是认证源JWT 是项目内部的会话凭证。也就是说小程序每次启动先用 code 换 JWT之后所有业务接口只认 JWT不再关心微信登录态。具体的视图逻辑大概长这样class WechatLoginView(APIView): permission_classes [AllowAny] def post(self, request): code request.data.get(code) result wechat_service.code2session(code) openid result.get(openid) user, created User.objects.get_or_create( openidopenid, defaults{nickname: 微信用户} ) profile, _ UserProfile.objects.get_or_create(useruser) refresh RefreshToken.for_user(user) return Response({ access: str(refresh.access_token), refresh: str(refresh), profile_completed: profile.is_completed, })注意 code 是一次性的如果同一个 code 被重复提交微信那边会直接报错所以前端必须保证登录请求只发起一次。另外 session_key 后端拿到后只用来解密手机号或做其他敏感操作不能随便存 Redis这个数据严格来说属于会话密钥泄漏会影响安全。3.2 租车订单提交与支付车辆列表和详情相对简单真正的难点在下单这一环节因为这里是并发冲突最严重的地方。用户提交订单时前端传过来车辆 ID、取车门店、还车门店、开始时间和结束时间后端要做这几件事校验车辆存在且状态为“可预约”校验起止时间在合理范围内开始时间不能早于当前时间结束时间必须晚于开始时间调用计费模块算出预估租金和押金检查这个时间段内车辆有没有已被占用的订单由于存在并发这一步必须做成原子操作或通过数据库约束保证生成订单号和支付记录返回支付参数。防并发这一块我用的是“数据库字段乐观锁 Redis 分布式锁”双保险。用户在车辆详情页看到的是缓存中的可约状态真正下单时会先抢一把 Redis 锁锁的 key 按车辆 ID 和时间段拼接抢到锁之后再去数据库里查订单表确认没有重叠时间才创建订单。锁超时设置为 5 秒避免极端情况下死锁。支付这边接微信支付统一下单接口后端生成预支付交易会话标识小程序端拿到后调wx.requestPayment。服务端实现支付签名时最容易出错我直接给大家一段实践中稳定使用的核心代码import hashlib import random import string import time import xmltodict def build_pay_params(order, total_fee, description): params { appid: WX_APPID, mch_id: WX_MCH_ID, nonce_str: .join(random.choices(string.ascii_letters string.digits, k32)), body: description, out_trade_no: order.order_no, total_fee: str(total_fee), spbill_create_ip: 127.0.0.1, notify_url: WX_NOTIFY_URL, trade_type: JSAPI, openid: order.user.openid, } sign wx_sign(params, WX_API_KEY) params[sign] sign xml_data xmltodict.unparse({xml: params}) resp requests.post(WX_UNIFIED_ORDER_URL, dataxml_data.encode(utf-8), headers{Content-Type: text/xml}) resp_data xmltodict.parse(resp.text)[xml] return resp_data签名函数里需要把参数按字典序排列后拼接 keyvalue再在末尾拼接 api_key做 MD5 或 HMAC-SHA256。调统一下单接口时total_fee的单位是“分”别把元传进去这个问题十个联动开发至少有三个会踩。支付回调是另一个重点。回调地址必须部署在公网能访问到的 HTTPS 路径下接收微信服务器转发的 XML 报文。后端要做验签验签通过后先查询订单确认金额再更新订单状态。回调接口必须是幂等的因为微信会重试多次不能因为重复回调就把订单状态重复置为已支付。我的做法是先判断订单状态只有“待支付”才会更新其他状态直接返回成功。还有一个细节统一支付下单后如果用户没支付就退出了订单会一直停在“待支付”。我加了个定时任务超过 15 分钟的待支付订单自动取消并把支付的 Redis 锁释放掉这样车辆时间窗口重新释放对真正想下单的用户才友好。3.3 取车/还车流程实现取车和还车是这个产品体验上的胜负手。用户不需要去门店柜台办手续到达取车点后打开订单详情页扫描车挡风玻璃边上的二维码就能开始用车。二维码设计是这样的每台车在其基本表里存了一个唯一的取车码由运营在录入车辆时生成打印出来内容是一个带签名参数的长串。小程序扫描到二维码之后把 code 提交给取车接口。后端取车接口的校验逻辑我按这个顺序写校验订单状态必须是已支付校验当前时间在计划取车时间前后 1 小时内太早取车要额外收费所以严格限制校验扫到的取车码属于订单上的那辆车确认车辆当前没有被其他人使用。校验通过后订单状态从待取车改为使用中记录实际取车时间同时车辆状态变为使用中并且推送一条模板消息给用户。还车流程用的是“先拍照、后结算”。用户点击还车后需要上传最多六张车辆照片照片上传接口走小程序的上传接口直接到对象存储后端只接文件 URL。图片上传之前要校验文件类型和后缀虽然对象存储那边可以限制但业务层还是加了一层保险。照片上传完成后前端调用还车接口后端把订单状态改为待结算同时生成一条结算费用明细。如果实际还车时间在预计时间之后系统自动计算超时费如果之前有租赁期间产生的其他费用也一起加入。最后把结算单返回给前端用户确认后点击“确认支付”支付差额整个订单走到已完成押金原路退回。我之前想过要不要让用户先确认再生成超时费后来实际操作下来发现这样流程太长用户很容易在中间一步卡住。最终方案是还车时系统生成费用明细明确列出超时金额、基础租金、押金退还金额用户如果对费用没有异议需要手动勾选同意并点击“确认结算”流程才算关闭。如果有人工申诉场景运营可以在后台人工调整调整后重新推送结算单给用户。3.4 优惠券、保险与会员的扩展设计这些不是第一版的核心功能但我在数据模型里预留了位置因为这类业务迟早要做。优惠券表的核心字段是券类型满减券、折扣券、无门槛券、使用门槛金额、抵扣金额、生效与失效时间、适用范围指定车型或全部车型。我在订单提交接口里预留了 coupon_id 参数下单时校验券是否可用、是否已被使用确认可用后把优惠金额计入订单费用明细同时锁定优惠券防止同一张券在多个订单中被并发使用。这里的锁机制和车辆时间锁类似都是先查后改配合数据库状态字段做的。保险这块租车行业基本都会提供“基础保障费”和“无忧免赔服务”。第一版我把它做成订单结算里的可选商品选择后增加对应费用并在订单扩展表里登记保险方案类型。这样后续对接保险公司理赔接口时可以直接从订单扩展表里取数据和车辆、用户信息。会员体系最直接的应用是“会员日租金折扣”和“积分抵现”。这些计算都放在计费模块里传入用户会员等级返回对应价格。商城积分功能如果需要也可以基于 Django Admin 的扩展能力快速搭建但首版不用堆功能保证核心链路稳定更重要。4. 小程序端开发要点4.1 页面结构与组件划分小程序端的页面我按业务域拆成了六个主包页面和三组核心组件。主页面首页、车辆列表、车辆详情、下单页、订单列表、个人中心。另外还有实名认证、押金说明、取还车帮助等几个独立页面。组件方面做了三块复用度高的vehicle-card组件车辆列表和首页热销区共用接收车辆对象渲染图片、品牌、座位数、租金date-range-picker组件因为原生picker只支持单日期选择租车的取还车时间需要自己封装一个双日期选择器联动计算并显示总天数order-status-timeline组件在订单详情页展示一条时间轴让用户知道自己当前在哪个环节。写这些组件的时候最大的坑是事件通信。原生小程序没有类似 Vuex 那样的全局状态流我用了页面getApp()上的全局数据加behavior混入的方式做用户状态同步。首页判断用户是否已认证、下单页判断用户是否已填写驾驶证信息都依赖这份全局数据。登录态失效时后端返回 401 状态码前端在请求拦截器里统一跳转登录页而不是每个接口单独处理。4.2 地图与位置选择自驾游场景里地图是刚需用户要做两件事查看车辆所在取车点位置、选择还车点门店。小程序生态里地图组件我用的是微信原生map它支持 marker 点标记和 polyline 路线绘制不用额外集成第三方 SDK。但要把门店位置展示成 marker需要后端把门店的经纬度一起返回。选还车门店页面用了个小技巧在小程序chooseLocation接口返回用户选择的位置后再调用后端接口计算距离最近的可用门店。距离计算不需要地理围栏那么复杂直接用地球上两点间的弧长公式即可from math import radians, cos, sin, asin, sqrt def distance(lng1, lat1, lng2, lat2): lng1, lat1, lng2, lat2 map(radians, [lng1, lat1, lng2, lat2]) dlon lng2 - lng1 dlat lat2 - lat1 a sin(dlat / 2) ** 2 cos(lat1) * cos(lat2) * sin(dlon / 2) ** 2 return 2 * asin(sqrt(a)) * 6371这里有个容易被忽略的权限问题chooseLocation需要在 app.json 里声明requiredPrivateInfos字段并申请用户隐私授权否则在真机上一调接口就直接拒绝。我第一版开发工具里测得好好的上线体验版才发现授权弹窗弹不出来就是漏了这个配置。取车点导航功能我也做了。用户在订单详情页点击“导航前往”小程序端直接用wx.openLocation打开系统地图进行路线规划。这个接口只需要传经纬度和名称比自绘 route 省事得多体验也稳定。4.3 支付与授权注意事项支付调起很简单但有一个细节要专门说wx.requestPayment的参数必须直接来自后端统一下单接口返回的参数订单号、随机串、签名都不能二次拼装。如果前端自己拼签名十有八九会失败。另一个容易踩的问题是用户隐私授权弹窗。2023 年下半年开始小程序平台对用户信息获取审核特别严格用户在小程序里点击“实名认证”后后端不能直接向用户索取身份证和驾驶证照片必须通过小程序提供的隐私协议弹窗流程。所以在实名认证页面我用了wx.requirePrivacyAuthorize引导用户同意隐私政策通过后再弹出实名信息填写表单并单独向用户说明这些信息仅用于租车身份核验。还有一个使用体验上的优化支付成功后不要立刻关闭页面做下一步操作而是等待后端支付回调完成状态更新后再刷新订单详情。因为回调是异步的如果用户支付完马上看到订单还是“待支付”会以为钱丢了。我在订单详情页做了一个 3 秒轮询逻辑调支付成功后每 2 秒查一次订单状态查到已支付自动刷新页面。5. 项目部署与上线避坑5.1 服务端部署架构服务端的部署拓扑是这样的一台 4 核 8G 的云服务器部署 Nginx、Gunicorn、MySQL、Redis对象存储用来放车辆图片和用户上传的还车照片。这套配置对日均几千单的租车业务完全够用甚至还有富余。Gunicorn 我起了 4 个 worker每个 worker 跑 Django 应用。数据库连接池用了django-db-connection-pool避免高并发时 MySQL 连接数被打满。Redis 主要承载三块数据车辆可约状态的缓存、用户 JWT 刷新令牌缓存、微信 access_token 的缓存。access_token的缓存非常关键。第一次做微信支付时我每下单就调一次获取 access_token 的接口后来发现微信官方接口对access_token的请求频率有限制一天超过一定次数会直接被封禁。正确做法是缓存到 Redis设置 7000 秒过期凭据快过期时才刷新一次。类似这种第三方凭据的缓存策略在对接支付、地图、短信等外部服务时都要注意。部署细节上需要注意 Nginx 需要拦截大文件上传对象存储的上传是前端直传不会经过 Nginx这里不涉及。但如果用的是 Django 自带FileField上传就要考虑 Nginx 的client_max_body_size要调到足够大否则图片稍大一点就被 413 挡掉了。5.2 小程序平台侧配置小程序上线要过的关比服务端部署多而且每一关都容易卡住。首先是合法域名配置。小程序后台的 request 合法域名必须是 HTTPS且不能是 IP 地址。开发者在开发工具里能勾选“不校验合法域名”但体验版和正式版不受这个开关控制所以域名和证书必须提前准备好。我给业务方的建议是域名用单独的二级域名比如api.example.com不要和官网主域名混在一起方便后续迁移和证书管理。其次是业务类目审核。租车小程序目前在小程序平台的类目里属于“出行与交通”下的“租车”类目审核时需要提供营业执照和相关的行业资质证明。这个环节业务方如果资质不全很容易被打回。建议在项目启动前就让业务方去确认类目条件和资质材料而不是等代码开发完再来补材料时间成本差距非常大。最后是用户隐私保护指引。小程序管理后台需要配置收集的信息类型比如姓名、身份证号、位置信息、手机号码同时声明对应用途。没有配置隐私保护指引正式版在调用chooseLocation、获取手机号这类接口时会直接报错。这个配置在开发阶段不会暴露往往上线前一两天才发现很影响排期。5.3 数据安全与合规租车业务涉及用户身份证、驾驶证、位置信息安全合规马虎不得。我在项目里做了这么几件事数据库中的身份证号和驾驶证号用 AES-256 加密存储加密密钥放在服务器环境变量里不走代码仓库后端接口返回用户信息时做了字段级脱敏身份证只显示前三位后两位所有写操作统一记录操作日志订单状态变更、押金退还、优惠券使用都留下审计记录小程序端收集的位置信息仅在用户授权后调用并明示用于“选择取还车门店”。这里特别提一句微信支付退款和押金退回的操作有风控规则频繁对同一用户发起小额退款或大额退款可能触发平台风险预警。我给运营后台加了退押金人工复核按钮默认不自动触发原路退回而是订单完成后由运营一键确认退款。这样既保证资金安全也能避免不必要的风险提示。6. 常见问题与排查实录6.1 支付回调掉单怎么处理支付掉单是租车项目里最让人头疼的问题之一。现象是用户微信已经扣款但后端订单状态一直停在待支付用户投诉说“钱扣了车不能用”。排查思路是这样先看支付回调日志确认微信服务器有没有把回调报文送到指定路径。如果根本没有回调日志那就是回调地址不可达检查域名、证书、Nginx 转发配置。如果回调日志有但验签失败重点看签名拼接的字符集、参数顺序特别是appid和mch_id的顺序对不对。为了防止掉单我还加了一个补偿机制订单详情页拉起支付前先调用后端的“主动查询订单接口”后端拿着订单号向微信查询支付结果如果查到已支付则直接把订单状态修正为已支付。这样即使回调丢了用户在支付后刷新一下订单详情也能自己触发修复逻辑。最后的兜底是定时任务扫描超过 30 分钟仍处于待支付的订单主动向微信发起订单查询。我用下来这套“回调幂等 主动查询 定时扫单”的组合基本上能做到 100% 对账没有出现过用户扣款但订单一直挂起的情况。6.2 接口报 401 和跨域问题小程序请求后端只要配置了合法域名不存在浏览器同源策略那种跨域问题。但在开发调试时如果用网页端管理后台去调接口就会遇到 CORS 问题。我使用的是django-cors-headers这个库按域名白名单方式配置生产环境只允许后台管理域名。需要特别注意的是CORS 配置中CORS_ALLOW_CREDENTIALS要设为 True否则后台登录请求携带 Cookie 会被浏览器拦截。同时CORS_ALLOW_HEADERS中要把Authorization加进去否则 JWT 请求头会被拒。401 的情况主要集中在小程序端 JWT 过期。SimpleJWT 的默认 access token 有效期是 5 分钟refresh 有效期是 1 天。5 分钟对小程序业务来说太短用户可能填写身份证表单填到一半 token 就过期了一提交就 401体验很差。我后来把 access token 调整为 7 天refresh 调整为 14 天短期业务安全性足够也能保证用户在租车周期内不用频繁登录。6.3 并发下车辆被重复下单同一辆车同一时间段被两个用户同时下单这是租车系统最容易出现的数据问题。除了前面说的 Redis 锁方案我还做了一个数据库层的兜底用车辆 ID 和订单时间窗口建了唯一约束的组合订单表但这个方案比较笨因为“时间窗口重叠”很难用唯一约束表达。我推荐的做法是“先锁车再下单”。用户点了下单按钮后后端先把车辆状态从“可预约”改成“预约中”再创建订单如果用户 15 分钟没支付导致订单自动取消再把车辆状态改回“可预约”。这样从业务语义上就把并发冲突化解了Redis 锁只是最后一道保险防止极端边界情况下两个人同时把状态从“可预约”改掉。实际操作中还有一个有趣的问题订单自动取消任务和用户主动取消订单可能同时操作同一条数据导致重复退款或者订单状态不对。我在取消逻辑里也用乐观锁处理更新订单状态时带上当前状态作为条件如果更新影响行数为 0说明有其他请求已经更新了这条记录就直接返回异常。6.4 一些值得沉淀的习惯最后分享几个我在这个项目里沉淀下来的小习惯不一定每个人都有用但至少对做同类项目的人应该有参考价值。写接口时统一使用drf-spectacular生成 OpenAPI 文档小程序端所有接口的参数和返回结构都以这份文档为准前后端联调时不用反复问“这个字段到底传什么”。文档虽然前期多花一点时间但后续维护接口、排查线上问题时省下的时间远超投入。所有涉及外部接口调用的代码都封装成独立的 service 模块比如wechat_service.py、pay_service.py、map_service.py。这样即便微信支付 SDK 升级或者换支付渠道改动只集中在一个文件里不会散落在各个视图函数中。订单号生成用时间戳 随机串 用户ID尾号的组合但要注意不能用UUID直接作为订单号因为微信支付对out_trade_no的格式和长度有要求太长或者有特殊字符容易报错。定时任务我统一用 Django management command 写然后用系统服务触发不依赖 Django 自带的后台任务这样出错时排查方便。备用调度也简单cron 配置里直接调用 management command 即可。比如自动取消超时订单、扫描支付掉单、释放过期 Redis 锁这几个任务在服务器稳定跑了大半个月没有出现过漏执行的情况。还有一点是日志。项目刚开始时我以为日志就是 print后来被坑了一次才发现线上排查问题没有结构化日志几乎寸步难行。这个项目里每个关键接口都记录了请求ID、用户ID、参数摘要、接口耗时、异常堆栈统一打到日志文件里。真出了问题按请求ID就能把整个链路的日志串起来效率提升非常明显。这个项目做到现在我已经把“登录-找车-下单-支付-取车-还车-结算-退款”整条链路跑通了至少几十遍。虽然还有很多可以优化的地方比如接车载智能硬件实现真正的远程解锁或者接入第三方违章查询接口做自动扣款但核心流程的稳定性和可维护性是我更看重的东西。如果你正准备启动一个类似的项目我个人建议先别急着加功能把订单状态机和支付对账这两块做扎实了后面加什么都稳。