接口返回错误码和 msg 的优劣势？

[gzk329]

code: 定义错误码
msg：“xxx error”

code: 5000
msg:"xxx 错误，请检查 xxx"

除了 msg 内少写一些内容，还有别的优劣吗？

[opengps]

code 是给程序用的，可以自己扩展写分支处理逻辑
msg 是给人看的，可以友好提示文本（这里不得不吐槽，很多程序没处理到友好的程度）

[mdn]

code 是给前端看的
msg 是给用户看的

[k9982874]

你只给个 msg 让前端做根据错误跳转页面，你看前端喷 不喷你

[fimd]

我这么多年来，接口一直来都是按这格式返回：
code: Success/Error/Empty
msg: 这是具体的文字提示
item: 这是业务信息内容
-----------------
大家提意见吧，欢迎拍砖

[IvanLi127]

我觉得

code 是给程序看的
msg 是给开发看的，要言简意赅
用户看的错误信息是前端自己结合 code 以及额外的错误信息给的友好提示

[kaedeair]

code 处理逻辑，msg 弹窗告诉用户，有 msg 定位错误快一些

[oppoic]

{"code":200,"msg":"操作成功"}
绿框提示 “操作成功”，并进行下一步（比如刷新页面）

{"code":403,"msg":"请先勾选再提交"}
红框提示 “请先勾选再提交”，页面保持不动

{"code":500,"msg":"未将对象引用到实例"}
红框提示 “网络异常，请稍后再试”，页面保持不动

403 和 500 的区别是：403 是逻辑错误，500 是后端抛错了，程序抛错信息不给用户看，让用户看友好提示，程序员按 12 可以看到，也可以去库里查更详细的抛错日志

[mdn]

@IvanLi127
1. 服务器内部错误，不应该暴露，应该从日志中查看
2. 表单中有太多错误提示，无法灵活处理，需要定义很多 code, message

[chendy]

有编码规则的字符串错误码，比如 模块_功能_编号 这样
纯数字的存起来能省点空间，但是实在算不上友好

[cnoder]

不能都返回吗

[index90]

FYI: https://cloud.google.com/apis/design/errors?hl=zh-cn

[nikenidage1]

日经话题了
个人推荐就是使用 http status code ，然后如果更详细的错误，也有 rfc 的规范可以标准化
https://www.baeldung.com/rest-api-error-handling-best-practices
https://blog.axway.com/learning-center/apis/api-design/introduction-to-rfc-7807

[NoKey]

有个争议，到底用 http 的 code 还是自己的 code ，这个目前还未分出胜负😁
如果使用自己的 code ，那么 code ，msg ，data （实际数据体），这 3 个参数一般都是同时出现，到底给谁的不在意，前端可以根据 code 来快速判定执行是否成功，如果执行失败，那么 msg 就是提示了，很多提示前端不不好去匹配的，后端直接给了就行

[flyqie]

{"code":1,"msg":"未知错误","data":{...业务数据}}

[IvanLi127]

@mdn

生产环境和 msg 大概就是一个 code 对应一两种 msg 文本，不想暴露的内容可以在程序里判断环境去输出，比如我负责的项目的登录结果，开发环境是具体说因为什么原因导致哪个环节登录出错，但是生产环境就的 msg 就只说“账号密码不匹配”和“账户锁定”。

表单的错误信息，比如 xx 字段不满足 xx 条件，这个信息是扩展的错误信息，扩展的错误信息可以是对象，能结构化地读取具体错误出来。msg 只是一个字符串，除非前端嗝屁了，不然这个信息不应该直接透传到 ui 上。

[Nazz]

我全都要

[lanweizhujiao]

接口返回错误码和消息（通常是一个简短的文本描述）是常见的做法，用于传达接口操作的结果和可能的错误信息。它们各自有一些优劣势，下面是它们的主要优点和缺点：

错误码（ Error Code ）的优势：

标准化和规范性： 错误码是一种标准化的方式来表示不同类型的错误。每个错误都有一个唯一的错误码，这有助于在不同的应用程序和系统之间实现一致性。

机器可读性： 错误码通常是数字或字符串，易于在程序中进行比较和处理。这使得自动化处理错误变得更容易，例如，根据错误码采取特定的恢复措施。

多语言支持： 错误码不依赖于语言，因此可以轻松地实现多语言支持，只需根据错误码查找相应的错误消息翻译。

性能： 错误码通常比文本消息更轻量，所以在网络传输和存储方面具有一定的性能优势。

错误码的劣势：

不直观： 错误码通常不直观，不容易理解。开发者可能需要查阅文档来了解每个错误码的含义，这可能会增加开发和调试的复杂性。

用户不友好： 对于最终用户来说，错误码通常不是一个友好的方式来了解问题，因为它们缺乏描述性的信息。

[lanweizhujiao]

6666666666

[MFWT]

个人写的很简单的小项目，最后采取的是 code+msg

code 为 1 就成功，0 就失败
具体发生什么事了，写在 msg 显示出来里让用户处理，比如『用户名密码错误』，『请输入有效金额（ 0-200 ）』

不知道有没有什么坏处？

[scegg]

code 比较好实现国际化。
不然要在后端提供本地化语言描述，导致两端都要处理语言。

[lanweizhujiao]

@mdn 文档

[xuanbg]

code 是用来处理不同分支逻辑用的，message 是抛出来给人看的。所以 code 定义有限的几个就行，message 要在抛出异常的地方定义。

[Orlion]

code: 方便排查问题，根据用户返回的 code 找到问题发生地
msg: 出现了问题，告知用户发生了什么以及如何解决

[liuidetmks]

@MFWT 一般 0 是成功，非 0 是失败

[mark2025]

@MFWT linux 下面习惯是 0： 成功， 非 0：失败。
这种方式，成功就一种，而失败就可以多种了。