做过十几个订单类系统后我们发现：让项目失控的从来不是"列表页怎么写"，而是两个底层模型没设计好——状态机和权限。把这两个想透，剩下的都是常规开发。
状态机：先画图，再写码
订单的本质是一个状态流转过程。第一件事情不是建表，而是和业务方一起画状态图：
- 状态要少而准：待付款、待发货、已发货、已完成、已取消，五个能覆盖八成业务。每多一个状态，流转路径就多一倍；
- 流转要显式：每个状态列出"谁、在什么条件下、能把它改成什么"。比如"已发货"只能由仓库角色从"待发货"流转，不允许任何角色直接跳到"已完成"；
- 禁止隐式修改：所有状态变更走统一入口，校验来源状态合法才执行，并且记录变更日志（谁、何时、从什么改成什么、原因）。
这张状态图就是我们和客户之间的"合同"：开发前客户确认图上的每一条线，开发后不会再出现"我以为还能改"的返工。
权限模型：RBAC 打底，数据权限收口
企业管理系统的权限有两个维度，分开设计：
功能权限——你能点哪些按钮。用经典的 RBAC：用户挂角色，角色挂权限点。注意权限点要细到操作级（"订单-导出"和"订单-查看"是两个权限点），粗粒度的"模块权限"后期一定会被打回来重做。
数据权限——你能看到哪些数据。这是最容易漏的：销售只能看自己跟进的订单，主管能看整个团队，财务能看全部但不能改。实现上推荐在查询层统一注入数据范围条件，而不是在每个接口里手写 if。
三个反模式，提前避开
- 状态字段用注释代替约束：数据库里没有任何状态约束，全靠代码自觉——迟早出现非法状态；
- 权限写死在代码里：加一个角色要改代码发版，应该后台可配置；
- 没有变更日志：出了纠纷查无可查，审计字段（创建人/时间、最后修改人/时间）从第一天就带上。
一句话总结
订单系统的设计顺序应该是：状态机 → 权限模型 → 界面。前两个在纸上就能定稿，界面反而是最不值钱的部分。