白条上征信已经是两年前的事情了. 哪家银行查到白条使用记录, 直接提高贷款利率? 哪个城市?

@ABenmao 也许吧, 哈哈. 如果我站在你的角度上, 我可能还会用这种思路去设计.
我比较倾向尽量少或者无人力去审查这些, 因为之前设计的错误码也是让专人去审查的. 我觉得这些时间与人力可以用在其他地方上. 还是让场景来决定设计吧.

@ABenmao #216 我给上家公司设计的错误码就是这种思路, 程序员知道错误码后能快速的定位到问题, 每个系统, 模块结合起来, 再加上特定的模块里的业务逻辑再定 3-4 位错误码, 最终设计出来的错误码直接飙到 7-8 位错误码. 结果后期要返回错误码的时候,需要找哪个错误码已经被用过了, 维护错误码又是一个重复的工作量. 我觉得这种设计不美观, 复杂, 繁琐, 不优雅. 后来我就根据逻辑处理来设计错误代码, 省去大量增长的错误代码查找工作. 与其让业务去做这些复杂重复的工作, 我为何不写个能跟踪问题所在的日志记录系统呢? 框架有存在意义就是帮程序员节省重复的劳动力, 专心做业务, 想往技术发展的程序员自然会去研究框架的实现技术.

自己写 RBAC2

@yamedie 你也说是因为 PM 后面脑洞大开时提出的, 与你当时写完后不给 code 并不冲突, 因为这是后面提出的改进. 并且 PM 提出这个需求, 你以评审是否有必要, 有则给开发新加个这种工作量需求, 没有那就驳回这个需求即可, 不是吗?

@yamedie 是的, 我不是前端. 我反驳的是 70xx 这种错误码无意义, 后面你的 9001 代码就有存在的必要, 因为前端需要根据这个固定代码来跳转到登录页面引导用户登录. 我的逻辑很简单, 前端需要根据返回的错误码来进行页面上的逻辑处理, 则规定一个具体代码, 如果没有逻辑处理, 定义那么多错误代码我是觉得没意义.

想一想, 验证码失效, 一个提示语告诉用户即可, 无需定义 7001 这种代码, 验证码校验失败也是一个提示语的事情, 7002 的代码无存在意义. 除非你们的产品经理有要求你们在有这种提示语时有特殊的界面交互动作, 那这 7002 的代码就有其存在的意义, 前端需要知道这个错误码, 才能做逻辑处理交互.

分布式事务 或 改队列

@yamedie 我觉得短信 70xx 的代码无任何存在的意义, 用户不关心错误代码是什么, 前端拿到错误代码也不做任务处理, 何必花时间与精力去维护越来越多的错误代码呢? 服务端写返回的时候还要去查代码是不是已经存在了. 这种错误包括但不限于: xx 输入不合法, xx 未填写, 校验不通过, 提交失败等 统一一个非 0 的 code 即可如 code: -1, 可适用于绝大部分的逻辑中断返回

把 Http 状态码再自己包装一层, 我个人觉得是没意义的事. 但是自定义 code 我是一直在用的, 并且就楼里所说, 我觉得什么情况下错误码够用? 你要自己去思考. 我在给公司设计错误代码规范的时候是规定, 如果前端需要服务端返回特定的 code 码来处理一些后续逻辑, 则给固定一个唯一的, 如果不需要, 仅仅是错误提示, 只要统一的错误码即可. 错误码在大部分情况下对前端及用户来说是无任何意义的(除非你想跟踪问题, 但是跟踪问题, 日志就可以了). 当然这种情况在写开放 api 接口的时候会参考 A,T 的错误码