评审一个外包项目的表结构，订单表里赫然一个status字段，备注写着「1待付款 2已付款 3已发货 4已完成 5已取消」，然后没然后了。问了一句：用户下单没付款，但运营在后台手动改成了已发货，数据还自洽吗？对面沉默了。订单表的数据库设计，状态字段是最容易被拍脑袋、返工起来最疼的一环。
一个字段装不下所有状态
订单其实同时有两条线：支付状态（未付、已付、已退款）和履约状态（待发货、已发货、已签收）。塞进一个status里，枚举值会爆炸——待发货已退款、已发货退款中、已签收部分退款，做不了几个版本，代码里就全是status == 6这类天书。正确做法是拆字段：pay_status、ship_status、refund_status各管各的，展示层再算一个「综合状态」给用户看，互不干扰。
流转规则要写成约束，不能靠自觉
状态从哪到哪是合法的，先画一张流转图，然后落到代码层面统一管控：只能从待付款跳到已付款，已完成的订单禁止再改任何状态。别让每个接口自己随手update状态字段，改状态的入口一多，脏数据指日可待，出了问题连是谁改的都查不到。
留一张流转记录表
建一张order_status_log：谁、什么时候、从什么状态改成什么状态、备注是什么。加这张表的成本几乎为零，但客服和用户扯皮的时候，它就是证据。做过售后的人都知道，一张流转记录能省掉多少口水仗。
见过一个更隐蔽的坑：状态字段用字符串存，代码里有的地方比「已付款」，有的地方比「paid」，有的地方比大写「PAID」，三种写法并存两年没人发现，直到对账脚本上线才炸出来。所以状态字段建议统一用数字存，含义写进备注，展示文案在代码里统一映射，从根上杜绝各写各的。
两条建议：开工前让开发画出订单状态流转图，你逐个状态确认了再建表；验收时故意造几笔异常订单，比如给已完成订单申请退款，看系统能不能拦住非法流转。比格网络做订单类系统时，状态机和流转记录是数据库设计的标配交付，这类设计花小钱，防的是日后的大坑。
