是的，go的net包在windows上自1.9起深度集成iocp，仅用于net.conn相关网络i/o（如listen、accept、read、write），不适用于文件或进程操作；os.open、os/exec.command等仍走同步win32 api。
Go 的 net 包在 Windows 上确实走 IOCP，但只限于网络 I/O
net.Listen、net.Conn.Read/Write 这些调用底层已接入 WSARecv、WSASend 和 AcceptEx，并由 CreateIoCompletionPort 管理完成通知。但这个“接入”是 runtime 层封装好的，你无法通过修改 net.Conn 行为去控制投递粒度或完成键语义。
关键限制在于：IOCP 仅覆盖 net 包，不延伸至 os、io/fs、exec 或任何文件路径操作。这意味着：
-
os.Open("config.json")仍是同步CreateFileW + ReadFile，阻塞 goroutine 所在的 M 线程 -
filepath.WalkDir遍历目录时每一步都触发同步FindFirstFileW - 模块缓存读取（如
GOROOT/pkg/mod/cache/download）全程无 IOCP 参与
压测时 QPS 比 Linux 低不是 IOCP 不行，而是路径断层明显
Windows 上 HTTP server 压测吞吐不如 Linux，常见原因不是 net/http 的连接收发慢，而是以下三处同步瓶颈被放大：
Windows TTS (WSL2)
下载
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
- TLS 握手依赖
crypto/rand→ 最终调用CryptGenRandom，该 API 不走 IOCP，且在高并发下易成为锁争用点 -
http.ServeHTTP中若含os.Stat或http.Dir静态文件服务，每次请求都触发同步文件元数据查询 - 短连接场景下，
SetKeepAlivesEnabled(false)导致频繁closesocket+AcceptEx重投递，NTFS 句柄表压力陡增，错误码常为ERROR_TOO_MANY_OPEN_FILES（实为句柄耗尽）
想验证 IOCP 是否生效，别看代码，看线程状态
启动一个 net/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 - 手动管理
OVERLAPPED内存生命周期（不能分配在栈上，需池化或堆分配） - 放弃
net/http，改用gnet或自己写 event loop（gnet的eventloop_windows.go是目前最成熟的封装） - 注意
runtime.MLock配合内存池使用——否则 GC 可能移动WSABUF.buf指向的缓冲区，导致内核写入野地址
IOCP 不是开关，而是一整套资源契约。你一旦降级到 syscall 层，就同时承担了句柄泄漏、重叠结构复用错误、完成键混淆等风险——这些在标准库里被刻意隐藏，但真实存在。
