写接口文档时，同事在订单对象里同时放了 state 和 status 两个字段，前端看完问了一句这两个不一样吗，会议室安静了三秒。翻代码才发现，一个表示订单流程走到哪一步，另一个表示这次请求成没成功，混着用，后面谁都说不清。

一个说自身 一个说结果

state 描述对象自己处在什么状况，是它内部的一组取值，比如订单的待付款、已付款、已发货、已完成，通常配一个状态机，合法的流转路径是固定的，不能从待付款直接跳到已完成。

status 更多是外部给的标签，或者一次交互的结果。接口返回 success、failed，后台任务标记 pending、running，都属于这一类。英文语感上也对得上：state 偏客观存在的状况，status 偏被赋予的身份或者进度，所以健康检查叫 status，组件内部数据叫 state。

落地时先定一条规矩

最省事的规矩是一个实体只留一个状态字段。订单用 state，取值写成枚举，数据库里存 tinyint，配一张字典表；接口最外层统一用 status 表示调用结果，别在业务对象里再塞一个同名的字段，读代码的人会一次次停下来猜。

命名上还有个小坑：status 的复数是 statuses，state 的复数是 states，拼错在 ORM 里会直接报找不到列。团队最好把这两个词写进命名规范，新增字段前先对照一眼，比事后改表省事。接口文档里的字段说明跟着一起改，别只动代码不动文档。

已经混用了怎么收

老项目里两个字段都在跑，别急着删。先把各自含义写成注释，再在接口层做一层映射，把业务状态统一暴露成 state，把结果码收敛到外层 status。前端按新字段改完，观察一两个版本，确认没人读旧字段再删。

判断标准其实很朴素：这个值会不会按固定路径随时间变化，会就用 state；它只是在回答这次操作成不成、这个对象能不能用，就用 status。想不清就先画状态流转图，画不出来，多半说明这个词从一开始就用错了。改字段名要趁早，等接口被三四个端调用之后再动，就得排期了。