直接调用 syscall.Read/Write 会卡住整个 OS 线程（M），导致绑定其上的所有 goroutine 暂停调度；而 os.File.Read 走 runtime 封装的非阻塞路径，fd 注册进 netpoller，G 挂起时 M 可继续执行其他 G。
直接调用 syscall.Read 或 syscall.Write 在 Go 协程中几乎总是错的——它会卡住整个 OS 线程（M），导致绑定其上的所有 goroutine 暂停调度，Go 的并发模型瞬间退化为单线程阻塞模型。
为什么 os.File.Read 不卡 M，而 syscall.Read 会
因为 *os.File.Read 内部走的是 runtime 封装好的非阻塞路径：fd 被注册进 netpoller（Linux 用 epoll_ctl，Windows 用 IOCP），goroutine 等待时只是挂起自身（G 状态变为 Gwaiting），M 立即返回去跑其他 G；syscall.Read 是裸调用，运行时完全不可见，内核一阻塞，M 就真睡死，P 长期卡在 _Psyscall 态，sysmon 都难抢回来。
常见错误现象：
- 单 P 下起两个 goroutine，一个死等
syscall.Read(os.Stdin, buf)，另一个time.AfterFunc(100ms, ...)完全不触发 -
GODEBUG=schedtrace=1000输出里持续出现Psyscall行，且不切换回Pidle
从 C 传入的 fd 怎么安全复用
若必须用外部传入的 fd（如 CGO 返回的 int），可用 os.NewFile(uintptr(fd), "name") 包装成 *os.File，再调 Read() —— 但这只在 Unix/Linux/macOS 有效；Windows 下该方式无法将 HANDLE 关联到 IOCP，仍可能阻塞 M。
实操建议：
- Unix 系统：确保 fd 已设
O_NONBLOCK（用syscall.SetNonblock(fd, true)），再os.NewFile，能走 netpoller - Windows 系统：放弃
os.NewFile，改用golang.org/x/sys/windows手动调ReadFileEx+OVERLAPPED，并配好完成端口 - 更稳妥做法：避免接收裸 fd，改用
socketpair、pipe或 Unix domain socket 等 Go 可控通道传递数据
真要裸调非阻塞 syscall？三个条件缺一不可
仅当你在实现零拷贝协议栈、对接硬件驱动、或绕过标准库做极致性能优化时才考虑。此时必须同时满足：
- fd 已设非阻塞：Unix 下用
syscall.SetNonblock(fd, true)；Windows 创建时必须带FILE_FLAG_OVERLAPPED - 显式告知调度器：调
runtime.Entersyscall()进入系统调用前，runtime.Exitsyscall()返回后 —— 否则 runtime 仍按默认阻塞逻辑处理，P 会被长期霸占 - 错误码判断完整：Unix 下需同时检查
errno == syscall.EAGAIN和errno == syscall.EWOULDBLOCK；Windows 下必须区分ERROR_IO_PENDING（异步进行中）和真实错误
真正容易被忽略的是：哪怕你完成了全部技术动作，裸 syscall 仍绕开 runtime 的 netpoller 统一事件循环，失去超时控制、取消支持、以及与其他 I/O 的公平调度能力。
