关于业务返回码的问题。

[awanganddong]

和客户端对接项目，然后遇到了以下问题，想问下大家怎么操作的。

一种报错，属于后台的校验类或者属于代码側的错误。

比如说 用户 type 类型有误，该数据操作失败。

这种情况属于通用报错，我们直接返回 400 报错码，然后由客户端自己提供报错信息。

还有一种属于业务类型的报错，我们返回特定的报错码。报错信息由服务端提供。

比如 400001 该用户已被封禁。

现在问题就在于产品会增加弹窗提示需求，这时候是不更包的。所以就想问下大家的处理方案。

比如增加 400002 该用户涉嫌违规，请谨慎操作。

---

如果 code 不变，内容更改如何。

[devswork]

增加一个新接口，用于返回指定状态码和提示信息、提示类型绑定列表，每次客户端启动，就请求和缓存最新的列表，客户端获取后端错误码后，根据弹窗类型和提示信息进行提示？

[Chad0000]

建议在网关处理。api 返回 400002 ，网关检测到客户端是旧版本则修改描述或者返回码。

[tianmalj0613]

建议先和前后端统一一下 API 的错误码规范，在错误详情中设计一些 action(如弹窗、重试、退出登录等)，错误提示语，用于告知客户端的下一步动作。

[awanganddong]

@devswork 这个我想下，我是不太想通过接口来实现
@Chad0000 网关处理我觉得太复杂了
@tianmalj0613 现在就是和大家讨论下平日里的技术实现。

[owen800q]

不用错误碼，后端直接传中文信息，如果要国际化就叫前端加 accepted language header ， 前端会感谢你的

[awanganddong]

我现在又新增了一个类别

code1 通用错误码
code2 特殊错误码 ，支持客户端弹 toast
code3 临时错误码， 客户端只用把对应 msg 返回即可。

[Chad0000]

OP 你需要考虑一下越简单越有效的原则，你加太多规则会导致客户端受限太多，如果客户端想要改，那么新旧版本升级将更复杂。你现在只需要考虑兼容旧版客户端，要么在代码里实现，要么网关拦截。

想像一下如果你设计得足够复杂，那么 API 甚至都可以直接返回终端布局+数据，那么前后端绑得就越深了，一更改影响太多。

[awanganddong]

@Chad0000 现在我直接在代码里实现了。客户端也仅仅通过 code 码的位数来进行区分。

整体还是非常简单的。

[zjsxwc]

还是没看懂。
“增加弹窗提示需求”与“业务返回码”有什么关联吗？