@Ayanokouji #1 哎，现在就像看看能不能直接用它提供的回调，现在看来是不行的

我们是两个都用，当没有冲突的时候直接提 pr ，当有冲突的时候从 master 创建一个新的分支然后把 feature 合并到新分支之后 使用新的分支再提 pr

我要是弄出来这么个东西也挺不好意思给别人说是我设计的

@cj323 #18 你是我见过的为数不多的说 go 官方文档写的好的

@lveye 这两天也在看这个，其中的 custom method 搞得我是懵逼了

@ryalu #49 怎么这么老长的代码

@xz410236056 #88 除了出身不好，那都好

@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 的路子比较野，现在就想看看比较好的规划是啥样的