timidsmile2021-07-08对于使用 httpCode 表示业务逻辑的情况（针对 错误码设计方式的第二种和第三种），统一监控如何区分是自身服务问题还是业务问题呢？ 比如，对于 500 类错误，如何区分是自身服务panic等导致的，还是上游请求数据有问题(yaml data couldnt be encde 等)造成的呢？ 会不会让监控变得复杂？作者回复: 你们的监控如果一定要区分这两种情况，那只能从业务code上区分了。 如果感觉从业务code区分比较麻烦，那可以将yaml data couldnt be encode这种错误，再映射为一个HTTP Status Code，比如：512。 这种复杂度，是不可避免的，因为监控是一定要感知到差异的，这些差异要么来自于业务code，要么来自于http status code
共 3 条评论4
Allen2021-11-24新浪微博API应该是国内互联网应用最早最广的API，确实很有参考价值。作者回复: 新浪微博的缓存系统设计的也是很NX
3
咖梵冰雨2021-11-11var _ errors.Coder = &ErrCode{} 请问这一段代码有什么作用作者回复: 确保ErrCode实现了errors.Coder 接口，如果没实现，在编译期间就能发现错误。
3
静心
2021-10-19关于错误码，我觉得最好尽量使用HTTP状态码进行判断。因为毕竟老师也说了，避免解析Body。在rfc7231规范中占用了600以下的状态码，在这些状态码中512~599尚未被注册使用，有一定的保留空间。所以600以上的就可以用于自定义的状态码。作者回复: 感觉不太适合，原因如下： 1. HTTP的状态码和业务的状态码其实不是一回事情，强行放一起，会有点乱。 2. 如果使用HTTP状态码，就意味着，错误码是有限的，而且还比较少。不利于系统的演进，因为随着系统规模的扩大，错误码很容易突破HTTP闲置状态码的个数。 3. HTTP状态码不能包含更多的信息
2
宙斯2021-07-06三种设计方式有两种返回http 404 Not Found，是写错了吗？编辑回复: 收到反馈，我们和老师确认下 老师的回复：“没写错哈。虽然后面2个HTTP status code返回的是一样，但是response body中返回的错误信息丰富度是不一样的。”
共 2 条评论2
李凯2022-11-06 来自广东这套错误码如何根据header lang参数，进行中英文切换作者回复: 这个还没有实现，你可以网上搜下实现方法，并尝试实现。带着问题去学习，这种学习效果更好
1
Sam Fu2022-10-27 来自广东问题1：可以维护一套错误码管理系统。用户在后台手动创建维护，然后系统在启动时加载系统所有的错误码。业务在处理完客户端响应时，由中间件统一实现返回response reference字段，如果业务方显式指定reference字段，则中间件不再覆盖。 问题2：整个业务组只维护一套错误码管理后台。错误码具有如下三个属性： - code - message - 是否是预期之内。 优点如下 - 统一错误码使用，如请求参数错误对应错误码为200010。因为如果不统一的话，不同团队对「请求参数错误」的错误码就不一样了。整体的使用会很乱。 - 错误码本身有个字段标识是否预期之内，这样可以单独对这个字段加监控报警，减少运维压力。作者回复: 666
1
CQS2021-07-07孔老师你好，我在github 仓库上看到你留有微信我添加并没有通过。麻烦能不能通过一下或者拉我进群一起学习？作者回复: 加了哈，已入群
共 3 条评论1
helloworld2021-07-07有一个疑问：公司的技术架构如果采用微服务的话，可能有上百个服务，错误码的服务部分只预留两位数，是否会不够用，还是说将微服务分成服务类，以减少服务数量呢作者回复: 如果真的需要很多服务，那错误码可以再多一位。 规范是人定的，具体需要看是否匹配业务，规范如果不匹配业务，需要修改之前的规范，并形成新的规范，都是可以的。
1
流星泪2022-06-09 来自广东对内和对外的错误信息，对内可以有敏感信息，对外展示给用户的是安全信息 怎么设计接口返回message，对内对外是不一样的呢？ 日常开发中，我们不都是通过日志记录敏感错误信息 去定位问题吗作者回复: 对内对外是可以不一样的。返回的错误中也可能有敏感信息