Windows上go run慢的本质是冷启动阶段依赖同步文件I/O，os.Open、filepath.WalkDir等均未接入IOCP，导致线程阻塞；真正提速应改用go build + 直接执行。
Go标准库在Windows上仍大量使用同步I/O路径
Go的net包、os包和os/exec等核心模块，在Windows上并未全面切换到IOCP。比如os.Open、filepath.WalkDir、exec.Command启动子进程等操作，底层仍走Win32 CreateFile/ReadFile同步调用，而非CreateIoCompletionPort+异步ReadFileEx。这意味着哪怕只是读一个go.mod或遍历GOPATH/pkg目录，都会阻塞线程——而go run恰好密集触发这类操作。
IOCP支持仅限net包部分路径，且默认不启用
Go 1.19+在runtime/netpoll_windows.go中引入了实验性IOCP支持（通过ioSqe标志控制），但该支持目前只覆盖net.Conn相关的网络读写，且需显式启用环境变量：
-
GODEBUG=asyncpreemptoff=1不是必须，但GODEBUG=netdns=go可能间接影响IOCP调度优先级 - 真正启用IOCP netpoll需编译时加
-gcflags="-d=netpoll"（仅调试用途，非生产） -
http.Server默认仍走WSAEventSelect模拟层，除非手动设置Server.SetKeepAlivesEnabled(false)并配合net.ListenConfig{Control: ...}接管socket
go run慢的本质：冷启动阶段完全绕不开同步文件I/O
go run的瓶颈不在运行时，而在构建前的依赖解析与临时文件生成环节：
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 读取
GOROOT/src/fmt/fmt.go等标准库源码 → 调用os.Open→ 同步CreateFile - 扫描
go.sum和模块缓存 →filepath.WalkDir→ 同步遍历NTFS目录项 - 写入临时
C:\Users\XXX\AppData\Local\Temp\go-build...\a.exe→ 同步CreateFile+WriteFile - 这些路径全部未接入IOCP，也无法被
netpoll接管，因此无论Go版本多新，go run在Windows上的4–5秒延迟仍是硬伤
真正能绕开IOCP短板的实操选择
别指望靠升级Go版本让go run变快——它从设计上就不是为高频调试优化的。更现实的做法是切断对同步I/O密集路径的依赖：
- 开发阶段一律用
go build -o app.exe main.go && ./app.exe，首次构建约300ms，后续执行就是纯进程启动开销（ - 用
air或reflex监听文件变化并自动go build，避免手敲命令；它们自身也应配置为跳过.git/vendor等大目录的监听，减少FindFirstFile调用 - 若必须用
go run（如CI脚本），至少确保GOCACHE指向SSD路径，且关闭Windows Defender实时扫描%LOCALAPPDATA%\go-build
IOCP不是银弹，Go标准库里那些没被标记// +build windows,io的代码，至今还在用ReadFile一帧一帧啃磁盘。
