Go 的 net.Conn 默认是非阻塞的，由运行时自动调度 goroutine，无需手动实现类似 Java NIO 的轮询机制；用户应使用同步风格代码，配合超时控制和并发优化。
Go 本身没有 NIO 概念，net.Conn 默认就是非阻塞的
Java 的 NIO 是为了解决传统 BIO（每个连接一个线程）在高并发下的资源瓶颈，核心是用少量线程通过 Selector 轮询多个通道。而 Go 的 net.Conn（比如 tcpConn）底层基于 epoll/kqueue/iocp，但**对用户完全透明**——你调用 conn.Read() 或 conn.Write() 时，Go 运行时自动将其挂起并让出 P，不占用 OS 线程，等 IO 就绪后再唤醒 goroutine。这本质上就是“协程化的非阻塞 IO”，无需手动注册、轮询或处理 OP_READ/OP_WRITE。
所以你不需要、也不应该去“实现类似 Java NIO 的东西”。直接用 net.Listener + goroutine 即可：
ln, _ := net.Listen("tcp", ":8080")
for {
conn, _ := ln.Accept() // Accept 也是非阻塞的，由 runtime 调度
go func(c net.Conn) {
buf := make([]byte, 1024)
for {
n, err := c.Read(buf) // 阻塞写法，实际是非阻塞语义
if err != nil {
break
}
c.Write(buf[:n])
}
c.Close()
}(conn)
}
为什么不能用 SetNonblock(true) 手动设非阻塞？
Go 标准库明确禁止用户对 net.Conn 底层文件描述符调用 SetNonblock(true)（会 panic），因为 runtime 需要完全控制 fd 的状态才能正确调度 goroutine。如果你强行绕过（比如用 syscall.Syscall 直接操作 fd），会导致：
-
Read()立即返回syscall.EAGAIN或syscall.EWOULDBLOCK，但 Go 的 runtime 不再监听该 fd 就绪事件 - goroutine 卡死或反复忙轮询，失去调度意义
- 与
netpoll机制冲突，可能引发 panic 或数据丢失
简言之：Go 把非阻塞细节全收走了，你只管写同步风格代码，它替你做异步调度。
立即学习“Java免费学习笔记（深入）”；
需要精细控制 IO 时机？用 runtime/netpoll（不推荐）
极少数场景（如实现自定义 reactor、对接 legacy C 库、调试 netpoll 行为）才需接触底层。Go 内部的 runtime/netpoll 提供了 pollDesc 和 netpolladd 等函数，但这些是未导出、无文档、随时可能变更的内部 API。官方明确不承诺兼容性，生产代码绝不可依赖。
如果你真遇到标准 net 包无法满足的 IO 控制需求（比如超低延迟绑定特定 poller、自定义就绪判断逻辑），更可行的路径是：
- 用
epoll_wait/kqueue等系统调用写 CGO 封装，绕过 Go runtime 的网络栈 - 改用
io_uring（Linux 5.1+）配合golang.org/x/sys/unix直接驱动 - 接受 Go 的调度模型，优化 goroutine 开销（如复用 buffer、减少逃逸）
常见误判：“为什么我的 goroutine 还是卡住了？”
看起来像“阻塞”，往往不是 IO 层问题，而是：
-
Read()卡住：对方没发数据、没关闭连接、TCP 窗口满、中间设备丢包 —— 这是网络行为，不是 Go 阻塞 - 没设
SetReadDeadline()，导致无限等待；应始终配超时：conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 大量 goroutine 同时
Write()大数据块，触发 TCP 缓冲区满，write 系统调用会阻塞（此时 Go 仍能调度其他 goroutine，但该 goroutine 会等缓冲区腾出空间） - 用了
sync.Mutex或channel在 handler 中串行化处理，成了人为瓶颈
真正要注意的，从来不是“怎么非阻塞”，而是“怎么不让 goroutine 因超时、锁、错误重试逻辑而堆积”。IO 本身，在 Go 里早就是轻量且自动的了。
