Go标准库在Windows上仅net包启用IOCP，os/filepath等仍用同步I/O；需手动调用windows.CreateFile+ReadFileEx或使用gnet等框架绕过标准库才能真正利用IOCP。
Go标准库在Windows上仍大量走同步I/O路径
go 1.19+ 虽在 runtime/netpoll_windows.go 中引入了 iosqe（iocp模拟层），但仅限于 net 包的监听/连接/收发等网络操作；os、filepath、io/fs 等包在 windows 上依然使用 createfile + readfile 同步调用，不投递到 iocp。这意味着 os.open、filepath.walkdir、模块缓存读取等行为，全部阻塞线程，无法并行化。
net 包启用 IOCP 后的实际效果有限
即使你用的是 Go 1.22，net.Listen 和 conn.Read 底层已走 IOCP 路径，但性能提升集中在高并发长连接场景（如万级 TCP 连接）。对常见 CLI 工具、小规模 HTTP 服务或单次请求响应模型，IOCP 带来的吞吐优势几乎不可测——因为瓶颈根本不在网络 I/O，而在 os.Stat、exec.LookPath 这类文件系统操作上。
-
go run main.go启动慢？主因是同步读取GOPATH/pkg/mod缓存和GOROOT/src的 .go 文件 -
http.Server在 Windows 上压测 QPS 上不去？先检查是否启用了SetKeepAlivesEnabled(true)，否则连接频繁重建会掩盖 IOCP 效果 -
net/http的 TLS 握手仍部分依赖crypto/rand→os.ReadFile→ 同步读取/dev/urandom模拟，Windows 下实际调用CryptGenRandom，但该 API 不走 IOCP
想真正利用 IOCP，得绕过标准库
Go 标准库不会为你自动把所有 I/O 切到 IOCP。如果你需要极致 Windows I/O 性能，必须主动降级：
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
- 用
golang.org/x/sys/windows直接调用CreateIoCompletionPort、WSARecv、GetQueuedCompletionStatus - 避免
os.Open，改用windows.CreateFile+windows.ReadFileEx投递异步读 - 第三方框架如
gnet已封装完整 IOCP event loop（见其eventloop_windows.go），但需放弃net/http，自己实现协议解析 - 注意：Go runtime 的 GC 和 goroutine 调度器仍基于 M:N 模型，IOCP worker thread 与 G-P-M 绑定关系不透明，过度混用易触发
runtime: mcpu=0或线程饥饿
IOCP 不是银弹，反而暴露 Go 在 Windows 的抽象断层
IOCP 要求操作前预分配 OVERLAPPED 结构、手动管理完成键、严格区分投递与完成上下文——这和 Go 的“面向接口、隐藏资源细节”哲学天然冲突。标准库为保持跨平台一致性，宁可牺牲 Windows 原生性能，也不愿在 os.File 上暴露 IOCP 特有字段或方法。所以你看到的现象是：同一个 net.Conn.Read 调用，在 Linux 走 epoll_wait，在 Windows 走 IOCP，但返回的错误码、超时行为、缓冲区生命周期管理却刻意保持一致——这种一致性，是以放弃部分底层控制权为代价的。
