@Immortal #7 咋说呢，我们现在的场景也有 traceID 上下文也能关联起来，现在使用的是 slog ，添加这个 traceID 也是挺恶心的，不单需要重新赋值 request ，还需要自己实现 slog 的 handler

@Div1ne #3 gorm 现在都已经实现了这些功能，不需要自己再实现一遍，有基于 logger 和 slog 的两种实现

@Immortal #1 我的想法是在最上层的错误处理器里统一处理 error 并记录相关的错误信息而后返回 response ，但是我再使用 gorm 的时候，我希望在查询出错的时候能记录到 error 和执行的 SQL ，但是 gorm 返回的错误并没有携带 SQL 语句，如果要记录 gorm error 时执行的 SQL 就需要使用 gorm 自己的 Logger ，这样感觉就会把错误信息切分成两部分，我的错误处理器中记录一部分，如果要查询具体的 SQL 就需要去 gorm 的日志中查看

@QlanQ #59 好像最近出了一个规范添加了一个 Query Method 来解决这个问题

感觉这种帖子没啥意义，有喜欢 restful 的，有喜欢 rpc 的，有喜欢 graphql 的，最终讨论不出来个啥，自己权衡利弊之后，选择一个比较适合自己场景的，然后制定好各种规范就 OK 了

必然是 PHP

那你如何解决后续的任务迭代的问题，感觉现在这个问题对我们有比较大的困扰

完蛋，我都是 new

啊，是这么处理吗，我都是在入口处理，内部基本都不捕获异常

今年 3 月份，出现了严重的过敏后就出现了高频耳鸣，一直持续到现在，去了同仁医院看了看，医生说这个耳鸣不好治，做了一下听力的检查，高频（ 8000HZ ）已经听不见了，医生说没有太好的办法，只能持续观察看看听力还会不会下降。

@weiwenhao #110 感谢大佬的回复，有点理解了

感觉很不错呢，但是有一个比较疑惑
```
fn delay_sum(int a, int b):int {
co.sleep(1000)

return a + b
}
```
为啥不是这样
```
fn delay_sum(a, b: int):int {
co.sleep(1000)

return a + b
}
```
这是比较细节的点，是有什么更好的考虑吗

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

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

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

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

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

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

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