syscall.read 会卡住整个 m，因为阻塞式系统调用使 m 进入内核休眠，脱离 go 调度器控制，导致其绑定的 p 无法调度其他 g；而标准库 os.file 和 net.conn 已自动集成 netpoller，实现 g 挂起、m 继续工作的协作式非阻塞 io。
Go协程里直接调用阻塞式系统调用（比如 syscall.Read、syscall.Write 或 Windows 的 ReadFile）会导致整个 OS 线程挂起，进而阻塞其他 goroutine —— 这不是你想要的并发效果。
为什么 syscall.Read 会卡住整个 M？
Go 的 G-M-P 调度模型中，每个 OS 线程（M）可运行多个 goroutine（G）。但一旦某个 G 执行了传统阻塞系统调用（如未设置 O_NONBLOCK 的文件描述符上的 read），运行时无法感知其何时就绪，只能让该 M 进入休眠，导致绑定在它上面的所有待调度 G 都停滞。
- Unix/Linux 下：必须提前用
fcntl(fd, F_SETFL, O_NONBLOCK)设置非阻塞标志 - Windows 下：需配合
OVERLAPPED结构 +WSARecv/ReadFileEx，且不能直接用syscall.Read - 即使设置了非阻塞，
syscall.Read返回EAGAIN或WSA_IO_PENDING后，你还得自己轮询或注册 IO 通知 —— 这就脱离了 Go 的 runtime netpoller 管理范围
更稳妥的做法：用 os.File + net.Conn 抽象层
绝大多数场景下，你其实不需要裸写 syscall。Go 标准库已把非阻塞 IO 封装进 *os.File 和 net.Conn 中，它们内部自动对接 runtime 的网络轮询器（netpoller），让 goroutine 在等待 IO 时挂起自身，不阻塞 M。
-
os.OpenFile("x.log", os.O_RDONLY, 0)返回的*os.File，其Read()方法默认就是协作式非阻塞（底层触发epoll_wait或IOCP） - 对管道、socket、tty 等设备文件，只要 fd 是由 Go 自己打开（而非通过
syscall.Open手动获取），就能享受调度器优化 - 若必须用已有 fd（如从 C 传入），可用
os.NewFile(uintptr(fd), "name")包装，再调Read—— 但注意：Windows 下此方式不支持异步 IO，仍可能阻塞
真要裸调非阻塞 syscall？绕不开的三个条件
仅当你要实现自定义协议栈、零拷贝收发、或对接特定硬件驱动时，才考虑手动包装非阻塞 syscall。此时必须同时满足：
- fd 已设为非阻塞模式（Unix：
syscall.SetNonblock(fd, true)；Windows：创建时指定FILE_FLAG_OVERLAPPED） - 使用 runtime 提供的
runtime.Entersyscall/runtime.Exitsyscall告知调度器：“我要进系统调用，但它是非阻塞的，请别把 M 挂起” —— 否则 runtime 仍按默认逻辑处理 - 错误码判断要完整：Unix 下检查
errno == syscall.EAGAIN || errno == syscall.EWOULDBLOCK；Windows 下检查GetLastError() == ERROR_IO_PENDING，并配合WaitForSingleObject或完成端口
真正难的不是调用本身，而是让裸 syscall 行为与 Go 调度器协同。多数人掉坑的地方，是以为“加了 O_NONBLOCK 就万事大吉”，却忘了 runtime 不会自动监听这个 fd 的就绪事件 —— 它只管自己打开的 fd。
