@zoharSoul 小技巧应该是有的

@selca 要的就是避免网络 IO😂

@NCE go-zero 对标的是 kratos 这种微服务解决方案. iris 没用过只知道是基于 fasthttp 的, 比 gin 重一点但功能远不如 go-zero 那么丰富. 看你自己的需求, 没用到 gRPC 的话 gin 够用了.

标准库够用了, 没必要上 fasthttp

type Row[K any] interface {
GetID() K
}

func ToMap[K comparable, V Row[K]](rows []V) map[K]V {
var m = make(map[K]V, len(rows))
for i, v := range rows {
m[v.GetID()] = rows[i]
}
return m
}

需要泛型

@lizhenda gws 在连接生命周期管理这块可以说是自动挡, IO 过程中一旦出现错误就会关闭连接

@lizhenda gws api 更清晰一些

大佬出书了我来买一本

@lesismal 好的, 我去 README 里面提醒下

@lesismal 下次更新把写操作的错误返回加上吧. 不打算在 gws 里面对广播场景做优化了, 如果有需要, 开发者可以自己为每个连接多开一个协程, 对于不需要处理广播的业务场景就节省了一般的协程. 确实, 用少量协程处理大量连接写入, 碰到大量慢连接的场景会很卡.

@lesismal async write 这块我还有个 idea ，可以维护一个全局的 WriteMessageQueue

@lesismal 异步 IO 适合「海量连接，少量活跃」的场景，连接太少跑 benchmark 就吃亏了😆

我就和基于 std net 的库比一比

@lesismal 标准库对于广大中小企业够用了；大厂没准会自研

@lesismal 笔误，开启了协程去处理业务逻辑.

@lesismal 以我多年 crud 的经验来看，似乎很少有人关心 write 是否返回了错误. 一般来说，在 write 之前业务逻辑都处理好了，或者开启了协程去处理错误，有错误关闭连接退出就好

@DefoliationM CloseCode 和错误处理比较恶心

@lesismal 使用 channel 异步写会增加一倍的常驻协程，我更倾向于广播的时候开启一小批临时协程

@lesismal 断开连接是自动的