go 的 net 包在 windows 上仅网络调用走 iocp，os/exec/filepath 等同步 api 绕过 iocp；确认 http server 是否真用 iocp 需查线程栈中 ntwaitformultipleobjects（wait reason=executive）及 iocompletionport 句柄；qps 较低主因是 crypto/rand、os.stat、频繁 closesocket 等同步瓶颈；要真正掌控 iocp，须绕过标准库，直调 windows api 或用 gnet 等框架。
Go 的 net 包在 Windows 上确实走 IOCP，但只限于 net.Listen、net.Conn.Read、net.Conn.Write 这类网络调用；os.Open、filepath.WalkDir、exec.Command 等全部绕过 IOCP，走同步 Win32 API——这不是配置问题，是标准库的明确设计边界。
怎么确认你的 HTTP server 真正在用 IOCP
别看代码有没有 net.Listen，得看线程实际行为。启动服务后，用 Sysinternals 的 Process Explorer 打开进程 → Threads 标签页 → 任选一个线程 → 点 Stack，观察调用栈：
- 若看到
NtWaitForMultipleObjects且 Wait Reason 是Executive，说明该线程正挂起在完成端口上 - 右键句柄列表 → Find Handle or DLL → 搜索
IoCompletionPort，应至少有一个类型为IoCompletionPort的句柄 - 如果只看到大量线程状态为
Running或Waiting（Wait Reason 是Event/Semaphore），那 netpoller 没生效——常见于自定义net.Listener实现但没绑定 IOCP
为什么压测 QPS 比 Linux 低 10–20%，不是 IOCP 不行
IOCP 本身在连接收发层已足够快，瓶颈往往卡在三处同步路径上，且它们和网络 I/O 完全解耦：
Handsfree Windows Control
下载
通过 handsfree-windows CLI控制 Windows 本机应用 (UIA) 和浏览器 (Playwright) 的引导技能，用于自动化或测试桌面应用。
-
crypto/rand在 TLS 握手时调用CryptGenRandom，该 API 不走 IOCP，高并发下易成锁争用点 - 静态文件服务（如
http.FileServer(http.Dir("."))）每次请求都触发os.Stat，同步查元数据，无法并行化 - 短连接场景下
SetKeepAlivesEnabled(false)导致频繁closesocket+AcceptEx重投递，NTFS 句柄表压力陡增，错误码常为ERROR_TOO_MANY_OPEN_FILES（实为句柄耗尽）
想真正用上 IOCP，就得绕过标准库抽象
Go 标准库不会帮你把 os.File.Read 改成 ReadFileEx，也不会暴露 OVERLAPPED 字段。你要获得完整控制权，必须：
- 用
golang.org/x/sys/windows直接调用CreateIoCompletionPort、WSARecv、GetQueuedCompletionStatus - 避免
os.Open，改用windows.CreateFile+windows.ReadFileEx投递异步读 - 第三方框架如
gnet已封装完整 IOCP event loop（见其eventloop_windows.go），但需放弃net/http，自己实现协议解析
IOCP 要求预分配 OVERLAPPED 结构、手动管理完成键、严格区分投递与完成上下文——这和 Go 的“隐藏资源细节”哲学天然冲突。标准库为跨平台一致性，宁可牺牲 Windows 原生性能，也不在 os.File 上暴露 IOCP 特有字段。所以你看到的 conn.Read 行为，在 Linux 走 epoll_wait，在 Windows 走 IOCP，但返回的错误码、超时语义、缓冲区生命周期管理，全是 runtime 封装后的统一表现——你没法干预底层完成包分发逻辑，也没法控制线程池规模或完成键语义。
