如果让我回答这题.

1. 首先 go 的协程的实现是跑在线程上面的，简单理解，就是一个在线程循环里面，从一个队列里面不停取 callback 执行，这个 callback 就是协程，一个 thread 默认要占用 10MB(当然线程也能调整默认栈的大小，只是会加大爆栈的可能性)。内存，一个 callback 可能只要 2KB(维护上下文的栈指针)。所以起 100w 个线程/协程，内存占用分别是
100 万个 10MB 对象：约 9.54 TB
100 万个 2KB 对象：约 1.91 GB ， 协程可以大量节约内存，所以算回答协程能做到，线程不好做到的事情

2. 协程可以提升 thread 的利用率，减少 cpu 摸鱼时间。
假如代入到 c 语言里面，你写了一个前面用 epoll 解析网络协议的代码+业务放在多线程里面处理。这里面要在业务代码访问第三方的 sdk ，而且还是阻塞式的 socket 。当调用到这个 sdk 时，你的线程就在阻塞。这时就会造成线程浪费(主要是内存)。如果换种方式，用 go 举例。同样使用第三方 sdk ，第三方的 socket 都被 epoll 管理，所以阻塞只要标记下阻塞的 callback 依赖 gobuf(协程栈)，这时候你的物理线程要不有活就干，没活就自我结束。当用时才有物理线程，就是利用率最高的表现。

付费 windsurf 。

3 和 4 之间, 3.7 左右。现在 windsurf 之流已经支持 ai agent ，让它重构一些小活，正确率很高。
现在类 4o 大模型的推理能力挺很强了，25 年估计都是加强 agent 这块，25 年过完，估计就能到 4.

感觉提供一个 vscode 插件会好些。

6 ，现在还用的 22.04

分享一个简单的方法。有问题直接问大模型，无论是部署还是写代码。

@asuraa 其实还好，如果用 copilot 的话，写个中文注释就自动补齐出 sql, 然后就用 sqlc 生成操作函数。

我周五放假写个推送服务，试下 ent 好不好使。

简单 crud 使用 sqlc 也挺爽的，直接写个 sql 生成函数。直接调用。

有点意思，先标记下，后面再研究。

你测试代码呢？可以把 fasthttp 也加进来一起测试下。

这边接口有问题，一看原来是腾讯云报的错。

每天。

可行，感谢。

同样，发不了消息。10 点到现在没有恢复。

我是直接开个 github issue 当博客用的。正好可以记录下碎片化的想法。

@rekulas 有一个简单的方法验证， 如果对端传过来的 gzip 包，都缓存到 bytes.Buffer ，完毕可以解出来。那就说明你的 io.Pipe 的用法不对。

因为 list.Accpet 只有新的连接过来，才会停止阻塞，所以这种写法的 go 程的个数等于连接 net.Conn 的个数。

另外聊个题外话，创建大量的 go 程，新版本 go 的 runtime 里面已经做了复用和优化。性能开销没有想象中那么大。
做过一个实验，使用 https://github.com/antlabs/quickws 这个 websocket 库，创建 100w 个 go 程，内存占用大约是 7.67GB 左右，8w tps 并发，50%的时延是 511.62ms

--------------------------------------------------------------
BenchType : BenchEcho
Framework : quickws
TPS : 86326
EER : 413.65
Min : -1ns
Avg : 573.50ms
Max : 1.44s
TP50 : 511.62ms
TP75 : 705.19ms
TP90 : 715.05ms
TP95 : 718.11ms
TP99 : 721.15ms
Used : 49.70s
Total : 5000000
Success : 4290729
Failed : 709271
Conns : 1000000
Concurrency: 50000
Payload : 1024
CPU Min : 120.52%
CPU Avg : 208.70%
CPU Max : 231.77%
MEM Min : 7.67G
MEM Avg : 7.67G
MEM Max : 7.67G