运营把「待发货」改成「等待发货」，后台按钮就集体消失了，状态文案到底该由谁来给？

状态字段用 0、1、2 表达，中文文案由谁提供，判断依据不是哪边写得省事，而是这套文案多久变一次、有几个端在消费、要不要按客户定制或多语言。按 2026 年项目交付经验，比较稳的分法是：接口只认原始状态码，展示文案由后端统一给出、或走一份字典接口，前端不参与翻译；前端写死中文，只在单端、状态少、文案长期不动的小系统里划算。下面把判断依据、现场代价和可核对的验收口径讲清楚。

状态码和展示文案，本来就是两件事

状态码是系统之间的契约，用来分支判断、查询、统计和存储；文案是给人看的，会随运营口径、品牌用语、客户定制和多语言变化。把两者塞进同一个字段，等于让给机器看的那个值跟着给人看的那个值一起改，改一次就要把所有分支逻辑回归一遍。

项目里能见到的典型反例是：接口返回 status 为「待发货」这样的中文串，前端拿字符串比较来控制按钮显隐；运营把「待发货」改成「等待发货」，按钮第二天集体消失。这不是前端粗心，而是码和名从一开始就没有分层。

除了页面，还有两个容易被忘掉的消费方：导出文件和运维日志。运营导出的 Excel 里状态列是 0 和 1，客服看不懂，只能回头问研发；值班查日志看到的也是数字，排查效率会明显下降。这两处恰恰更需要统一文案。

• 原始码：稳定、可枚举、有文档，只用于判断与存储，新增用新值，不复用旧值。
• 展示名：可改、可翻译、可按客户定制，只用于渲染，不参与条件判断。
• 语义级别：标明该状态属于进行中、终态还是异常，决定能否取消、能否退款、是否计入统计。

前端写死中文，一般从哪一步开始难受

交付现场常见的情况是这样：一套后台要同时给 PC 后台、小程序、App 三个端用，文案由运营按周微调，项目启动时没有统一术语表，工期又压得紧。第一版为了赶上线，三个端各自在前端写死了一份状态映射，当时看确实省了时间。上线约两个月后运营改了三处措辞，三个端要分别排期发版，版本没对齐的那几天，客服看到的说法和用户看到的对不上；后续返工改了两轮，其中一次还赶上小程序审核延期。这类代价不在开发当天出现，而是在文案第一次变动时才补交。

单端、文案几乎不变、也没有多语言计划时，前端写死确实省事，这一点不必否认。问题在于它把一个会变的东西塞进了发版周期：端数和文案变更频率只要有一个涨上来，维护成本就不是线性增长。按经验区间，2~3 个端并行时，一次措辞调整从提出到各端全部生效，常见区间是 3~7 天；如果走后端字典改配置，常见区间在几小时到 1 个工作日。

• 只在前端做映射，后端日志和导出文件里还是 0/1，运营对不上号。
• 同一个状态在不同页面写法不同，「已支付」和「支付完成」并存，客服话术对不齐。
• 后端新增一个状态值，老版本前端不认识，页面显示空白或 undefined。
• 国际化的需求提上来才发现，中文被当成了 key，映射要重写一遍。

三种分法的对比：改一次文案要动几层

分法各有代价，按「改文案要不要发版」「多端是否一致」「要不要国际化」三个维度看，结论会比较清楚。下面按 2026 年常见交付做法整理成经验区间，具体选哪种看端数和变更频率。

• 前端硬编码：改文案要发版，多端各写一套容易不一致，国际化基本要重做；适合单端、状态少、文案稳定的内部系统。
• 后端返回中文文案：改字典表或配置即可生效，多端天然一致，多语言可按请求头或租户切换；代价是接口多一个字段，文案要有人负责维护。
• 字典接口加前端映射：业务接口只给码，前端启动时拉一次字典并缓存；适合状态集合大、多模块共用的场景，代价是多一次请求和一份缓存，字典版本不一致时会短暂显示旧文案。

改一次文案的端到端时间，经验区间大致是：前端硬编码常见 1~3 个工作日（含回归和发版窗口），后端字典或配置常见 0.5~1 个工作日，字典接口方式在后续文案改动上接近后者，但首次搭字典要多花 2~5 天。状态在十几个以内、只服务一个端时，前两种方式差异并不明显；一旦超过两三个端，或者文案要按客户定制，后两种更省事。这里没有精确阈值，也不要为了统一，给只有两三个状态的小工具强行上字典体系。

码、名、义切好之后，验收看哪几条

之所以按码、名、义三层拆，是因为这三层的变更频率差得很远：码几乎不动，名一周可能改一次，义跟着业务规则走但很少动。把变更频率不同的东西放进同一个字段，必然互相拖累。

1. 先定码：数字或短字符串，写进接口文档，标注哪个版本加的、有没有废弃；新增只加不复用。容易漏的是废弃码，老数据里还留着，字典不写前端就渲染成空白。
2. 再定名：文案单独维护在字典表或语言包里，key 与码一一对应，允许一个码对应多语言或多套客户文案。
3. 后定义：列出每个码是否终态、能否取消、是否计入统计，这部分才是按钮显隐和后端校验的依据；别只做文案映射，按钮能不能点还写在前端 if 里。

验收时比较实用的合格线是三条：随便挑一条历史订单，运营、客服、开发三方看到的文案一致；新增一个状态，前端不改代码也能正常显示；导出文件里的状态列不是纯数字。三条过了，分层基本算落地，剩下的只是维护习惯。

适用与不适用边界

这套做法适合状态多、端多、文案会变的业务系统，比如订单、工单、审批流这类状态机明确的模块。反过来，状态只有启用/停用两个值、长期不改的后台，为它单独搭字典反而增加维护成本，投入和收益不成比例。

• 适合：状态在 10 个以上，或一年内新增过状态值；同一套后端要给两个以上端消费；有客户定制文案或多语言需求；导出、报表、客服后台都要看状态。
• 不必上：单端内部工具，状态两三个且长期不变；前端只做纯展示、没有任何按状态分支的交互；团队没有固定维护字典的人，加了反而没人更新。

要说清的边界是：码和文案分层，解决的是「改一次文案引发一串连锁修改」的问题，解决不了状态机本身设计混乱的问题。流转规则没理清，怎么分层都还是会乱，这时候该先梳流转，而不是先搭字典。

常见问题

后端直接返回中文文案，接口是不是就不通用了？

不会，但码要留着。常见做法是同时返回 status 和 statusText，判断只用 status、展示只用 statusText，以后换措辞或接多语言都不用改判断逻辑。

老版本前端不认识新加的状态码，一般怎么兜底？

遇到未知码显示「其他」或原始码，不要渲染成空白；文档里标注新增版本，按经验留一到两个版本的过渡期，常见区间是 1~2 个发版周期。

多语言场景，文案存数据库还是放语言包？

按变更频率分。运营会改的措辞放字典表，随代码走的固定文案放语言包；两边都用 key 关联状态码，别拿中文本身当 key，翻译一改就对不上。

状态文案全交给后端，接口会不会变重？

一个状态字段多几十字节，多数场景不是瓶颈。调用量大的列表页可以只回码、由前端查一次字典缓存，具体按实测结果权衡。

如果手上正有一套状态码散在各处的系统，可以先挑状态数比较多的那个模块，把码、文案、语义三列列出来，先让导出和日志用上统一文案，再逐步收敛前端写死的映射。端数少、状态稳定的内部系统不必强行改造，按现有方式维护、把码写进接口文档即可。