Go标准库在Windows下用IOCP但不暴露裸接口，因其调度模型（GMP）与IOCP线程池不兼容，所有I/O被runtime.netpoll封装以统一跨平台行为。
Go标准库在Windows上确实用IOCP，但你不能直接调用它
Go的net包在Windows下默认使用IOCP作为底层网络I/O模型，源码位于src/runtime/netpoll_windows.go。但它不是暴露给用户代码的API，而是运行时内部封装——你写conn.Read()或http.ListenAndServe()时，背后调度的就是IOCP完成端口，但这个过程完全透明。
这意味着：你无法在应用层手动创建CreateIoCompletionPort、提交PostQueuedCompletionStatus，也不能直接操作OVERLAPPED结构体。所有这些都被runtime.netpoll抽象掉了，目的是统一跨平台行为（Linux用epoll，macOS用kqueue）。
- 如果你试图用
x/sys/windows手动调IOCP API，会和Go运行时的IOCP实例冲突——比如两个线程池争抢同一个完成端口，导致GetQueuedCompletionStatus返回错误或挂起 -
net.Conn的阻塞/非阻塞语义由Go运行时控制，不是Winsock的ioctlsocket(SIO_NONBLOCK)；强行切换可能破坏goroutine调度 - 标准库中部分
x/sys/windows函数被标记为Deprecated（如CreateIoCompletionPort），因为签名不兼容原生Windows API，必须用x/sys/windows.CreateIoCompletionPort替代
为什么Go不让你碰IOCP裸接口？
根本原因是调度模型不兼容。IOCP是面向线程池的，而Go是GMP调度器（goroutine → P → OS thread）。如果允许用户直接调用IOCP，就必须自己管理线程生命周期、完成包分发、重叠I/O状态跟踪——这和Go“让goroutine处理I/O”的哲学相悖。
例如，一个典型的IOCP服务器要维护：
- 独立的完成端口句柄
- 至少
2 * CPU核心数个工作线程来调用GetQueuedCompletionStatus - 每个连接对应的
OVERLAPPED结构体及其内存生命周期（不能栈分配，不能GC回收） - 手动投递
WSARecv/WSASend并处理ERROR_IO_PENDING
而Go标准库把这些全收进netpoll循环里，用gopark挂起goroutine，等IO完成再goready唤醒——你看到的是同步写法，实际是异步执行。
在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……
想绕过标准库直接用IOCP？先看清代价
有场景确实需要直连IOCP，比如实现高性能命名管道IPC、对接Windows服务通信、或定制TLS握手流程。这时得用go-winio这类第三方库，它封装了安全的IOCP使用模式，且明确避开运行时netpoll。
关键限制点：
-
go-winio创建的winio.PipeListener不能和net/http.Server混用，必须自己实现accept-loop和goroutine分发逻辑 - 所有I/O buffer必须是
unsafe.Pointer指向的固定内存（不能是slice底层数组，防止GC移动） - 错误码要用
wsaErr := syscall.Errno(wsadll.GetLastError())转，不能依赖os.IsTimeout()等标准判断 - 关闭连接时必须显式调用
winio.CloseHandle()，否则完成端口可能收不到ERROR_NETNAME_DELETED类通知
性能差异其实没你想的那么大
在HTTP短连接或gRPC等主流场景下，Go标准库+IOCP的吞吐和延迟已经接近手写IOCP服务器。真正瓶颈往往在：
- JSON序列化/反序列化（
encoding/json比json-iterator慢2–3倍） - HTTP header解析（
net/textproto的bufio逻辑有额外拷贝） - goroutine启动开销（每请求1个goroutine vs IOCP里复用worker thread）
除非你压测到单机50万+并发连接、且每个连接持续双向流式传输（如实时音视频中继），否则不值得放弃标准库的可维护性去拼那几个百分点的IOCP裸调性能。
最容易被忽略的一点：IOCP本身不解决粘包、心跳、连接泄漏问题——这些逻辑无论用不用IOCP都得你自己写，而标准库的net.Conn.SetReadDeadline()和context.WithTimeout()已经帮你兜住了大部分边界情况。
