Go在Windows上IOCP仅限net包，os、TLS、文件操作仍同步阻塞，导致实际性能瓶颈；验证需查线程栈NtWaitForMultipleObjects及IoCompletionPort句柄。
go 在 windows 上用 iocp 并不等于“所有 i/o 都变快了”，实际执行损耗主要来自三处断层：net 包之外的同步阻塞、tls 和文件操作的非 iocp 路径、以及 runtime 封装带来的调度开销。你写 conn.read 是快的，但只要夹一个 os.stat 或 crypto/rand.read，线程就立刻掉回同步模型。
IOCP 只覆盖 net.Conn，其他 I/O 全是同步阻塞
Go 从 1.9 开始在 net 包中接入 IOCP，但仅限于：net.Listen、Accept、conn.Read、conn.Write、UDPConn.ReadFrom（1.21+）。其余全部走 Win32 同步 API：
-
os.Open→CreateFileW+ReadFile，阻塞 M 线程 -
filepath.WalkDir→ 每次调用FindFirstFileW，无法并发 -
http.Dir服务静态文件 → 每次请求触发GetFileAttributesExW和CreateFileW - 模块缓存读取（
GOROOT/pkg/mod/cache）全程无 IOCP 参与
HTTP server 压测 QPS 上不去？先查这三处同步瓶颈
Windows 下 net/http.Server 的吞吐短板往往不在网络收发，而在以下三类同步调用被高频放大：
- TLS 握手依赖
crypto/rand.Read→ 最终调用CryptGenRandom，该 API 不走 IOCP，且高并发下易锁争用 - 启用了
http.Dir或手动调用os.Stat查询文件元数据 → 每次请求都同步查 NTFS MFT - 短连接 +
SetKeepAlivesEnabled(false)→ 频繁closesocket+AcceptEx重投递，NTFS 句柄表压力陡增，错误码常为ERROR_TOO_MANY_OPEN_FILES（实为句柄耗尽）
想验证 IOCP 是否真在跑？别看代码，看线程栈和句柄
启动一个简单 HTTP server 后，用 Process Explorer（Sysinternals）检查：
- 筛选进程 → Threads 标签页 → 点任意线程 → Stack 中若出现
NtWaitForMultipleObjects且 Wait Reason 是Executive，说明线程正挂起在完成端口上 - 右键句柄列表 → Find Handle or DLL → 搜索
IoCompletionPort，应能看到至少一个类型为IoCompletionPort的句柄 - 若只看到大量 Thread 状态为
Running或Waiting且 Wait Reason 是Event/Semaphore，说明 netpoller 未启用或被绕过（比如自定义net.Listener但没绑定 IOCP）
真正用上 IOCP 的代价：放弃标准库抽象
Go 标准库不会为你把 os.File.Read 改成 ReadFileEx，也不会暴露 OVERLAPPED 字段。你要获得完整 IOCP 控制权，必须：
- 用
golang.org/x/sys/windows直接调用CreateIoCompletionPort、WSARecv、GetQueuedCompletionStatus - 避免
os.Open，改用windows.CreateFile+windows.ReadFileEx投递异步读 - 第三方框架如
gnet已封装完整 IOCP event loop（见其eventloop_windows.go），但需放弃net/http，自己实现协议解析
IOCP 不是开关一开就提速，而是把资源管理、状态跟踪、线程生命周期这些事全推给你——而 Go 的 GMP 调度器恰恰是为了隐藏这些细节。所以最常被忽略的点是：你以为在优化 I/O，实际是在和 runtime 的封装层打架。
