直接调用 syscall.read 或 syscall.write 会阻塞整个 os 线程（m），导致绑定其上的所有 goroutine 暂停调度，并发失效；应优先使用标准库封装的非阻塞 io（如 *os.file.read 或 net.conn.read），它们自动对接 runtime 的 netpoller，实现协作式调度。
直接调用 syscall.read 或 syscall.write 在 go 协程中几乎总是错的——它会卡住整个 os 线程（m），导致绑定在其上的所有 goroutine 暂停调度，并发优势彻底失效。
为什么 syscall.Read 会阻塞整个 M
Go 的 G-M-P 调度模型里，syscall.Read 是传统阻塞系统调用：一旦 fd 没设 O_NONBLOCK，内核会让当前 M 进入休眠，运行时无法感知就绪时机，也就无法唤醒其他 G。这不是“某个 goroutine 等待”，而是“整个线程挂起”。
- Unix/Linux 下：必须提前用
fcntl(fd, F_SETFL, O_NONBLOCK)设置非阻塞标志 - Windows 下：不能用
ReadFile直接调，得配OVERLAPPED+ReadFileEx，且需手动管理完成端口 - 即使设了非阻塞，
syscall.Read返回EAGAIN或WSA_IO_PENDING后，你还得轮询或注册通知——这已脱离 Go runtime 的netpoller管理范围
绝大多数场景下，你根本不需要裸调 syscall
标准库的 *os.File 和 net.Conn 已自动对接 runtime 的网络轮询器（netpoller），实现真正的协作式非阻塞 IO：goroutine 挂起时，M 可继续执行其他 G。
-
os.OpenFile("x.log", os.O_RDONLY, 0)返回的*os.File，其Read()方法底层触发epoll_wait（Linux）或IOCP（Windows），无需手动设非阻塞 - 对管道、socket、tty 等设备文件，只要 fd 是由 Go 自己打开（而非通过
syscall.Open手动获取），就能享受调度器优化 - 若必须复用已有 fd（如从 C 传入），可用
os.NewFile(uintptr(fd), "name")包装后再调Read()；但注意：Windows 下此方式不支持异步 IO，仍可能阻塞
真要裸调非阻塞 syscall？三个条件缺一不可
仅当你在实现自定义协议栈、零拷贝收发、或对接特定硬件驱动时，才考虑手动包装。此时必须同时满足：
- fd 已设为非阻塞模式：Unix 用
syscall.SetNonblock(fd, true)；Windows 创建时必须指定FILE_FLAG_OVERLAPPED - 显式告知调度器：“我要进系统调用，但它非阻塞”——调用
runtime.Entersyscall()和runtime.Exitsyscall()，否则 runtime 仍按默认逻辑把 M 挂起 - 错误码判断完整：Unix 下检查
errno == syscall.EAGAIN || errno == syscall.EWOULDBLOCK；Windows 下需处理ERROR_IO_PENDING并等待完成通知
真正容易被忽略的是：哪怕你完成了全部技术动作，裸 syscall 仍绕开了 Go 的 GC 友好内存管理、缓冲区复用（如 bufio.Reader）、以及连接生命周期控制（如 net.Conn.SetDeadline）。这些不是“额外功能”，而是保障稳定性的基础设施。
