go没有操作系统级异步i/o，其“异步”本质是goroutine阻塞时由调度器自动挂起并复用os线程，需通过errgroup、worker pool、超时控制和资源复用等手段实现高效可控的并发。
Go 本身没有操作系统级的异步 I/O（比如 io_uring 或 IOCP），所谓“异步 I/O”在 Go 中实际是「用 Goroutine 隐藏阻塞」+「调度器自动挂起唤醒」。框架能做的，不是变出真正的异步，而是帮你更稳、更省、更可控地组织这套机制。
为什么 net/http 和 database/sql 看起来“异步”但实际不异步
很多人误以为 http.Client.Do 或 db.QueryRowContext 是异步调用——其实它们是同步阻塞的，只是被 Go 运行时自动调度到空闲 M 上执行。一旦底层系统调用（如 read、connect）没返回，整个 Goroutine 就挂起，M 被释放去跑别的协程。
- 现象：1000 个并发
http.Get不会压垮线程数，但若所有请求都卡在 DNS 解析或 TLS 握手，Goroutine 会堆积，内存上涨，GC 压力飙升 - 本质：这不是异步 I/O，是协作式非阻塞调度 —— 依赖 runtime 对系统调用的拦截和 Goroutine 的状态切换
- 影响：如果你在 Goroutine 里做
time.Sleep、for {}或未设超时的net.Conn.Read，它就真阻塞了 M，拖慢全局吞吐
用 errgroup.Group 控制并发生命周期，别裸写 go func()
直接 go doTask() 在循环里启动几百个 Goroutine，是最常见也最危险的吞吐杀手。失控的 Goroutine 数量会吃光内存、触发高频 GC，甚至让调度器忙于管理而非干活。
- 正确姿势：用
errgroup.Group统一管理上下文取消、错误传播和等待完成 - 示例：
eg, ctx := errgroup.WithContext(context.WithTimeout(ctx, 5*time.Second))，然后eg.Go(func() error { return callAPI(ctx) }) - 关键点：ctx 超时后，所有正在运行的 Goroutine 会收到
ctx.Err()，可主动退出；没设超时等于放弃背压控制 - 坑：别在
eg.Go闭包里捕获外部循环变量（如for i := range tasks { eg.Go(func(){ use(i) }) }），要用参数传入
worker pool 比无节制 goroutine 更稳，尤其对 DB/HTTP 批处理
面对批量任务（如 1w 条日志写入、500 个第三方 API 调用），固定大小的 worker pool 能把资源消耗锁死，避免瞬时高峰打崩下游或自身。
- 缓冲 channel 是核心：
jobs := make(chan *Task, 100)+ 固定数量消费者 Goroutine（比如 20 个） - 对比：
for _, t := range tasks { go process(t) }可能瞬间创建 1w 个 Goroutine，栈内存暴涨，GC 频繁 STW - 选 size：缓冲区太小（如
chan *Task, 1）会让生产者频繁阻塞；太大（如10000）等于把压力转移到内存，且失去限流意义 - 配套：每个 worker 内部必须检查
ctx.Done()，并在退出前清空本地资源（如关闭临时文件、归还sync.Pool对象）
Zinx 等框架的“异步模型”到底优化了什么
Zinx 之类标榜“异步”的 Go 框架，真正提升吞吐的关键不在 I/O 层，而在任务调度与线程绑定策略上：它把耗时逻辑（如协议解析、DB 查询）从网络事件循环中剥离，交由独立 Goroutine 池处理，避免单个慢请求拖垮整个连接。
- 它不改底层
read/write行为，但通过 channel + worker pool 实现逻辑层解耦 - 某些场景下会用
runtime.LockOSThread()绑定 OS 线程（比如集成 C 库需 TLS 变量），但这属于极少数例外，99% 的业务代码不该碰 - 真实瓶颈往往在你自己的代码：没设超时的 HTTP 调用、没复用的
bytes.Buffer、没关的sql.Rows、没 flush 的bufio.Writer
吞吐量卡住时，先看 pprof 的 goroutine profile 和 allocs，再查 runtime.ReadMemStats 里的 Mallocs 和 NumGC——多数时候问题不在框架，而在你没管住自己 Goroutine 的出生和死亡。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
