业务系统里常常需要表达标准码覆盖不到的结果，比如账号状态异常、操作需要二次确认。于是有人干脆回到 200，把情况写在响应体里；也有人觉得不够清楚，另外加了一组数字。两种做法各有代价。
为什么会走到扩展这一步
从规范角度看，标准里的数字是有限的，官方并不鼓励随意扩充。但实际项目里，完全不扩也会让接口语义变得含糊。折中的做法是：标准码保持标准含义，业务层面的细分放在响应体里，需要额外提示时再用约定好的扩展字段。
- 第一步：判断层次 这是传输层问题还是业务层问题
- 第二步：优先复用 能用标准码表达就不要另造
- 第三步：约定扩展 确有需要时固定字段与取值，写入文档
- 第四步：保持稳定 取值一旦发布不再改动，避免下游误判
自造数字的代价
最大的代价是同步成本。自造的数字没有公共含义，所有调用方都要对着文档才能理解，一旦文档没跟上，行为就会失去依据。其次是中间环节的误解：代理IP转发、网关、监控工具都可能按标准含义解读这个数字，做出与预期不符的动作。
自定义的取值越多，需要同步的文档与调用方就越多，维护成本随之上升。能复用标准码时优先复用，是这个领域最省事的原则。
文档怎么跟上
文档要写明取值、含义与适用场景，并且说明它与标准码的对应关系。改动时同步更新，别只在代码里改。接口数量一多，没有这份对照，排查时就要靠反编译去猜。
代理IP监测里会遇到什么
用代理IP做接口监测时，自定义的取值往往会被忽略，只按标准码判断成败。结果是接口返回了一个自造的成功标记，监测却记成失败。判断前先确认监测工具是按标准码还是按响应体判定，能省下不少误报。
监测工具的判定口径
把口径写进监测配置说明里，换工具时先核对一遍。同一套接口用不同工具监测，结论出现分歧时，第一件事就是比较两者的判定口径。
扩展可以有，但要少而稳，并且写进文档，让所有调用方都能预期。
能复用标准码，就别另造。
把这一条当成接口设计的常规动作，扩展字段就不会成为日后维护的负担。