通过这样的设计，不论是程序还是人都可以非常方便的区分 API 的返回结果，关键是统一！
通常我们的 message 都是写给工程师看的，但是在不同的场景下，同样的错误，可能需要给用户看到不一样的错误提示。
比方说 20000-29999 表示订单创建失败：
这两种错误情况如果是给用户看，可能就只适合看到：很抱歉，您有一个正在进行中的订单，请到我的订单列表中处理。
但是对于 API 来说，返回的信息又必须是准确的，但用户看到的就必须转译，这个转译的工作调用方可以做，但是通常 API 提供者来提供个性化的 Message 能力会更好
我们可以把转译的消息配置到数据库，并缓存到 Redis 或者 API 本机
然后在请求处理结束即将返回的时候，根据 application_id+code，去匹配替换 message
这样我们就可以让手机 APP 的用户、微信小程序的用户、网页下单的企业用户看到不同的消息
有了统一的 code，我们就可以通过 Nginx 或者 APM 工具统计 API 请求 Code 数量及分布信息。
我们可以根据单位时间内 99999 的数量来做 API 的异常告警
我们可以根据 Code 的返回饼图，帮助我们发现系统、业务流程中的问题
等等
总之，好的返回码设计，可以帮助我们提高沟通效率，降低代码的维护成本
欢迎加入我的知识星球，一起探讨架构错误码，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇错误码，覆盖了MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 6W 行代码的电商微服务项目。
———END———
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，一年会员只需98元，全站资源免费下载 点击查看详情
站 长 微 信： bear68899
‘
