go net包仅对net.conn启用iocp，os.file等文件操作仍用同步i/o；真正利用iocp需绕过标准库，手动调用windows api或使用gnet等框架。
Go net包的IOCP封装只覆盖net.Conn，不碰os.File
Go标准库在Windows上对IOCP的封装是“有选择的”：它只在net.Conn生命周期内启用，比如Listen、Accept、Read、Write这些调用会走WSARecv/WSASend + GetQueuedCompletionStatus路径；但一旦涉及文件操作——哪怕只是os.Open("config.json")或http.Serve里读TLS证书——就立刻退回到同步CreateFile+ReadFile，完全绕过IOCP。
这意味着你无法靠升级Go版本让整个程序自动获得IOCP加速。常见误判场景：
- 看到
net.Listen("tcp", ":8080")成功启动，就以为所有I/O都异步了 - 压测QPS上不去，却只调大
GOMAXPROCS，没检查os.Stat是否在请求链路中高频出现 - 用
pprof发现大量goroutine阻塞在runtime.gopark，实际根源是filepath.WalkDir卡在NTFS句柄表查询
runtime/netpoll_windows.go 是唯一IOCP入口，且不可扩展
Go runtime中真正调用CreateIoCompletionPort、管理OVERLAPPED结构、分发完成包的逻辑，全部集中在src/runtime/netpoll_windows.go。这个文件被设计为“黑盒”：
- 它不暴露任何IOCP句柄或完成键（completion key）给上层，
netFD结构体里也没有字段可让你绑定自定义上下文 - 所有socket默认复用同一个全局IOCP实例，无法按业务域隔离（比如HTTP连接池和gRPC连接池共用一个完成端口）
- 错误处理是延迟的：
AcceptEx失败可能不会立即返回error，而是等几毫秒后才在netpoll循环中被netpollready捕获
你不能通过go:linkname或unsafe去劫持这个流程——runtime内部用pollDesc做状态机驱动，强行干预会导致runtime: mcpu=0或goroutine永久挂起。
在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……
想真用IOCP？必须绕开net/http和os包
如果你的应用确实卡在Windows I/O瓶颈（比如万级短连接+高频证书重载），唯一可行路径是放弃标准库网络栈：
- 用
golang.org/x/sys/windows直接调用CreateIoCompletionPort、WSARecv、GetQueuedCompletionStatus，自己管理OVERLAPPED内存生命周期 - 改用
gnet这类框架：它的eventloop_windows.go把每个连接的读写都封装成独立的iovec投递，并支持自定义完成键（比如把*Conn指针存进去），但代价是你要自己解析HTTP/1.1或实现TLS record层 - 避免
http.Server的Handler里调用任何os.ReadFile——把证书、配置预加载进内存，或用sync.Pool缓存bytes.Buffer避免每次分配
注意：crypto/rand在Windows下虽调用CryptGenRandom，但它仍是同步API，不走IOCP；高并发TLS握手时，这里会成为隐藏瓶颈。
IOCP不是性能开关，而是资源契约
启用IOCP意味着你承诺遵守Windows内核的资源契约：每个异步操作必须预分配OVERLAPPED，完成包必须及时消费，线程必须长期驻留等待GetQueuedCompletionStatus。Go标准库帮你扛下了这部分，但也锁死了灵活性。
最常被忽略的一点：IOCP的吞吐优势只在连接数远超CPU核心数时才明显。如果你的程序平均只有几百连接，或者90%时间花在JSON解析、DB查询上，那么IOCP带来的收益几乎为零，反而因OVERLAPPED内存分配、完成包拷贝引入额外开销。
