Go的net包在Windows上仅socket层走IOCP，os.Open等文件I/O仍同步阻塞；IOCP仅覆盖net.Conn.Read/Write和Accept，而配置读取、日志、TLS证书加载等均不受益，性能瓶颈常在此类同步路径。
Go 的 net 包在 Windows 上确实走 IOCP，但仅限于 socket 层
Go 从 1.9 开始在 net 包中启用 IOCP，但这个“启用”有严格边界：只覆盖 net.Conn.Read、net.Conn.Write、net.Listener.Accept 等基于 socket 的操作。底层调用链最终会走到 runtime.netpoll → WSARecv/WSASend/AcceptEx，并绑定到全局 IOCP 句柄。
关键事实是：os.Open、os.Stat、filepath.WalkDir、exec.Command 这些完全不走 IOCP——它们仍调用 CreateFile + ReadFile 同步 Win32 API，阻塞线程，无法被 goroutine 调度器异步化。
验证方法很简单：启动一个 HTTP server 后，用 Process Explorer 查看线程状态。若看到多个线程长期处于 WaitForMultipleObjects，且关联句柄类型为 IoCompletionPort，说明 netpoller 正在工作；但同时若发现大量线程卡在 ReadFile 或 FindFirstFile，那就是文件 I/O 拖了后腿。
为什么 net.Listen("tcp", ":8080") 不等于“整个服务都跑在 IOCP 上”
net.Listen 创建监听 socket 并绑定到完成端口，这一步确实触发了 CreateIoCompletionPort。但后续真正影响性能的，是连接建立后每条请求的完整路径是否保持异步——而 Go 标准库在这里有明显断层：
- HTTP handler 中调用
os.ReadFile("config.json")→ 同步读，阻塞 M - 使用
http.ServeMux时，路由匹配本身是同步字符串比较，无开销；但若中间件里调用crypto/rand.Read→ 底层模拟/dev/urandom，Windows 实际走CryptGenRandom，该 API 不投递 IOCP，也不支持超时控制 - TLS 握手阶段的证书加载、私钥解密等，若从磁盘读取 PEM 文件，仍是同步 I/O
也就是说：IOCP 只保住了“网络收发”这一段，而现代 Web 服务的瓶颈往往卡在配置加载、日志写入、模板渲染、模块缓存读取这些环节——它们全在标准库的同步路径上。
Go runtime 的 IOCP 封装隐藏了哪些关键细节
Go 把 IOCP 的复杂性封装在 runtime/netpoll_windows.go 和 internal/poll/fd_windows.go 里，对外只暴露 net.Conn 接口。这种抽象带来便利，也埋下三类隐患：
-
OVERLAPPED结构由 runtime 内部预分配和复用，你无法控制其生命周期；若在Write后立即Close，可能触发ERROR_IO_INCOMPLETE，但 Go 会静默重试或丢弃错误 - 完成通知的“完成键（completion key）”被 runtime 固定为
fd.sysfd，无法按业务打标；想区分控制连接 vs 数据连接的完成事件？做不到 -
GetQueuedCompletionStatus的超时参数由 runtime 统一设为 10ms，无法针对长连接/短连接做差异化调度；高延迟场景下容易出现虚假唤醒
更隐蔽的问题是：goroutine 被唤醒时，数据已拷贝进用户缓冲区，但缓冲区所有权仍在 runtime 手中。如果你在 handler 里把 conn.Read 返回的 []byte 逃逸到 goroutine 外部（比如塞进 channel），runtime 可能提前回收内存，导致读到脏数据——这不是 bug，是 IOCP + Go GC 模型天然耦合带来的约束。
真正想压榨 Windows 网络性能，绕不开手动 IOCP 调用
标准库不会帮你把 os.File 或自定义句柄接入 IOCP。如果必须突破限制，路径很明确：
- 放弃
net/http，改用gnet或自己封装；gnet的eventloop_windows.go直接调用golang.org/x/sys/windows的CreateIoCompletionPort、WSARecv、GetQueuedCompletionStatus，并管理OVERLAPPED生命周期 - 文件读写不用
os.Open，改用windows.CreateFile（带FILE_FLAG_OVERLAPPED） +windows.ReadFileEx；注意：ReadFileEx的回调函数不能直接调 Go 函数，需通过syscall.NewCallback转换 - 避免混用：不要在一个 goroutine 里既调
conn.Read（IOCP）又调os.ReadFile（同步）；M 可能被长时间阻塞，导致其他 goroutine 饿死
最常被忽略的一点：IOCP 不是并发加速器，而是资源调度器。它要求你显式管理缓冲区、重叠结构、完成键、句柄关闭顺序。Go 的“让接口隐藏细节”哲学在这里让步了——你要么接受标准库的保守封装，要么亲手接管 Windows 异步 I/O 的全部契约。
