是的，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-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 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 层，就同时承担了句柄泄漏、重叠结构复用错误、完成键混淆等风险——这些在标准库里被刻意隐藏，但真实存在。
