这是一个创建于 454 天前的主题，其中的信息可能已经有所发展或是发生改变。
code: 定义错误码
msg：“xxx error”
code: 5000
msg:"xxx 错误，请检查 xxx"
除了 msg 内少写一些内容，还有别的优劣吗？
 |
1
opengps 2023-09-05 15:41:02 +08:00
code 是给程序用的，可以自己扩展写分支处理逻辑
msg 是给人看的，可以友好提示文本（这里不得不吐槽，很多程序没处理到友好的程度） |
 |
2
mdn 2023-09-05 16:01:38 +08:00
code 是给前端看的
msg 是给用户看的 |
 |
3
k9982874 2023-09-05 16:05:59 +08:00
你只给个 msg 让前端做根据错误跳转页面，你看前端喷 不喷你
|
 |
4
fimd 2023-09-05 16:30:40 +08:00
我这么多年来，接口一直来都是按这格式返回：
code: Success/Error/Empty msg: 这是具体的文字提示 item: 这是业务信息内容 ----------------- 大家提意见吧，欢迎拍砖 |
 |
5
IvanLi127 2023-09-05 16:44:44 +08:00  1
我觉得
code 是给程序看的 msg 是给开发看的，要言简意赅 用户看的错误信息是前端自己结合 code 以及额外的错误信息给的友好提示 |
 |
6
kaedeair 2023-09-05 16:53:43 +08:00
code 处理逻辑，msg 弹窗告诉用户，有 msg 定位错误快一些
|
 |
7
oppoic 2023-09-05 18:01:00 +08:00
{"code":200,"msg":"操作成功"}
绿框提示 “操作成功”，并进行下一步（比如刷新页面） {"code":403,"msg":"请先勾选再提交"} 红框提示 “请先勾选再提交”，页面保持不动 {"code":500,"msg":"未将对象引用到实例"} 红框提示 “网络异常，请稍后再试”，页面保持不动 403 和 500 的区别是：403 是逻辑错误，500 是后端抛错了，程序抛错信息不给用户看，让用户看友好提示，程序员按 12 可以看到，也可以去库里查更详细的抛错日志 |
|
8
mdn 2023-09-05 18:12:06 +08:00
|
 |
9
chendy 2023-09-05 18:24:54 +08:00
有编码规则的字符串错误码，比如 模块_功能_编号 这样
纯数字的存起来能省点空间，但是实在算不上友好 |
 |
10
cnoder 2023-09-05 18:36:25 +08:00
不能都返回吗
|
 |
11
index90 2023-09-05 18:40:29 +08:00
|
 |
12
nikenidage1 2023-09-05 18:44:01 +08:00
日经话题了
个人推荐就是使用 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 |
 |
13
NoKey 2023-09-05 18:47:05 +08:00
有个争议，到底用 http 的 code 还是自己的 code ，这个目前还未分出胜负😁
如果使用自己的 code ，那么 code ，msg ，data （实际数据体），这 3 个参数一般都是同时出现，到底给谁的不在意，前端可以根据 code 来快速判定执行是否成功，如果执行失败，那么 msg 就是提示了，很多提示前端不不好去匹配的，后端直接给了就行 |
 |
14
flyqie 2023-09-05 18:48:17 +08:00 via Android
{"code":1,"msg":"未知错误","data":{...业务数据}}
|
|
15
IvanLi127 2023-09-05 19:41:21 +08:00 via Android
@mdn
生产环境和 msg 大概就是一个 code 对应一两种 msg 文本，不想暴露的内容可以在程序里判断环境去输出，比如我负责的项目的登录结果，开发环境是具体说因为什么原因导致哪个环节登录出错，但是生产环境就的 msg 就只说“账号密码不匹配”和“账户锁定”。 表单的错误信息，比如 xx 字段不满足 xx 条件，这个信息是扩展的错误信息，扩展的错误信息可以是对象，能结构化地读取具体错误出来。msg 只是一个字符串，除非前端嗝屁了，不然这个信息不应该直接透传到 ui 上。 |
 |
16
Nazz 2023-09-05 19:45:24 +08:00 via Android
我全都要
|
 |
17
lanweizhujiao 2023-09-05 19:49:39 +08:00
接口返回错误码和消息（通常是一个简短的文本描述）是常见的做法，用于传达接口操作的结果和可能的错误信息。它们各自有一些优劣势，下面是它们的主要优点和缺点：
错误码（ Error Code ）的优势： 标准化和规范性： 错误码是一种标准化的方式来表示不同类型的错误。每个错误都有一个唯一的错误码，这有助于在不同的应用程序和系统之间实现一致性。 机器可读性： 错误码通常是数字或字符串，易于在程序中进行比较和处理。这使得自动化处理错误变得更容易，例如，根据错误码采取特定的恢复措施。 多语言支持： 错误码不依赖于语言，因此可以轻松地实现多语言支持，只需根据错误码查找相应的错误消息翻译。 性能： 错误码通常比文本消息更轻量，所以在网络传输和存储方面具有一定的性能优势。 错误码的劣势： 不直观： 错误码通常不直观，不容易理解。开发者可能需要查阅文档来了解每个错误码的含义，这可能会增加开发和调试的复杂性。 用户不友好： 对于最终用户来说，错误码通常不是一个友好的方式来了解问题，因为它们缺乏描述性的信息。 |
|
18
lanweizhujiao 2023-09-05 19:50:28 +08:00
6666666666
|
 |
19
MFWT 2023-09-05 19:54:42 +08:00
个人写的很简单的小项目，最后采取的是 code+msg
code 为 1 就成功，0 就失败 具体发生什么事了，写在 msg 显示出来里让用户处理，比如『用户名密码错误』，『请输入有效金额（ 0-200 ）』 不知道有没有什么坏处？ |
 |
20
scegg 2023-09-05 19:57:07 +08:00
code 比较好实现国际化。
不然要在后端提供本地化语言描述，导致两端都要处理语言。 |
|
21
lanweizhujiao 2023-09-05 19:59:25 +08:00
@mdn 文档
|
 |
22
xuanbg 2023-09-05 22:26:37 +08:00
code 是用来处理不同分支逻辑用的，message 是抛出来给人看的。所以 code 定义有限的几个就行，message 要在抛出异常的地方定义。
|
 |
23
Orlion 2023-09-06 09:15:12 +08:00
code: 方便排查问题，根据用户返回的 code 找到问题发生地
msg: 出现了问题，告知用户发生了什么以及如何解决 |
 |
24
liuidetmks 2023-09-06 11:05:30 +08:00 1
@MFWT 一般 0 是成功，非 0 是失败
|
Select Language