@ericguo #8 全局设置的 header ，params 之类的，还是挺有需要的，一直有人提但是一直都没加

@ericguo #8 也不能说都有，一直有人提的一个功能，比如全局的环境变量，都没有，还有就是时不时的会崩溃一下

@sumarker #2 用起来挺好的，可惜就是现在不咋更新了

@Ayanokouji #48 怎么说呢，这就是 go 的特点吧，我们现在的做法就是每层都追加自己的信息，相当于手工造了一个堆栈

@tiedan #38 @harleyliao #4 这样真的好吗，我总的感觉就是 要么返回一个 error ，要么记录一个 error ，不要两件事都干

同样的问题，我也问过，怎么说呢，感觉 golang 这边没有啥统一的做法，看了看大佬意思就是 error 是一个 interface ，你自己想咋封装都可以

mac 再用，感觉还行

替我朋友问问

@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 就比较糙了，基本都是让前端去处理