@povsister #27 假设现在有两个角色，nginx -> server 当 nginx 不能拿到 server 的结果的时候应该是 504 吧，但是如果 nginx 能拿到 server 的结果但是 server 自己内部处理超时比如数据查询超时，这时候是不是返回 500 更合适

@povsister #25 刚看到你回复，我们公司的规模和体量确实比较小，技术的积累也没有那么多，所以设计的方案基本上都是参考其他公司的开放 api ，比如 微信支付 api （ v3 ），支付宝，stripe ，twilio 等对接过的公司的开放的 api ，发现他们有使用 http code 的，有不使用的。
我们对比了一下综合的就选了使用贴近 http code 的方式。使用下来的总的感受是没有遇到啥问题，可能就像你说的规模比较小可能也遇到问题。
我们使用下来的感觉是让上下游的处理更方便的，比如现在遇到 400 首先的猜测就是不是发起调用方的问题，遇到 500 那就首先排查是不是被调用方的问题。然后细节的问题就看具体返回的内容来判定。
感觉运维的监控做起来也比较容易，它只是单纯的关注 http code 就能知道大概的问题。比如遇到大量的 404 的错误，那就要怀疑是不是有人在循环抓取数据，遇到大量的 422 就怀疑是不是接口参数有问题，500 就要怀疑是不是服务的依赖组件有问题或者代码本身的问题。
能否分享一下你们遇到啥问题，才导致放弃来 http code 而使用全 200 加自定义错误的信息

@mcfog #21 也看到了 Join 方法，error interface 本身是比较简单的，现在就是在想这怎么把这些东西组合在一起，如果要丰富 error 的能力就要借助断言或者反射，感觉好像不太喜欢用这些

@soul11201 #19 感谢，等有时间了可以分享一下看看，我写 go 的路子比较野，现在就想看看比较好的规划是啥样的

@soul11201 #17 我们现在就在干这个事儿，所以就想看看大家的意见，以及有没有比较好的实践

@matrix1010 #8 感谢，这个我好好看看

@povsister #7 这个要不要使用 http code 感觉没有绝对的正确和错误，比如有些人就认为 http 是一个传输协议 http code 代表的 http 协议本身的成功和失败，那我们认为 http 是一个业务协议可以承载我们的业务信息

@rower #5 我们现在的分层上来说，是也框架解耦的，createUser 这个可能是 command 调用，也可能是 api 调用，这样的方法是脱离具体的框架的

@soul11201 #4 这个用 wrap 现在遇到一个问题，就是他会侵入到我自己的错误信息中，我只想要在日志中体现这个错误，而不想在错误信息中体现底层到底是啥错误

@mainjzb #2 这个意思就是需要自己自定义错误，封装自己需要的信息，感觉 go error 这一块一直不太容易把握

我们针对这种处理是分端的，针对客户端 后端的工作量比较大，基本上所有的数据都是处理好之后返回，客户端基本不做业务上的转换。针对 web 就比较糙了，基本都是让前端去处理

@ZztGqk #1 多年后端，写前端遇到的最大的问题就是不会布局，一个单位就搞的自己晕头转向，px, rem, vh ... ，每次写起来都焦头烂额的，感觉现在唯一能写的就是 管理后台了，就这样也是照葫芦画瓢，不过更大的可能是自己太菜了。

@yb2313 #6 这个东西简直就是魔鬼，我们有些同事特别喜欢用这个

是的，项目都归档了

服务端开发，我们就比较简单了，开发的起点是 master ，从 master 创建 feature 分支，不同的项目需求创建不同的分支，然后合并到 test 进行测试，上线的时候后把 feature 直接合并到 master 。不过这么做也有一个小问题，大家在功能测试的时候比较容易互相影响，但是总体还是可控的。

再结合前两天看到的，密码门锁的 虚位密码 感觉又是另一种情形了！

咋感觉少了一种情况，就是 明文请求，hash 存储

@Tomatopotato #5 我也从 dark 模式改到这个了，感觉适应了也挺好的