Go网络I/O默认基于epoll+非阻塞模式，runtime自动设置O_NONBLOCK并接管fd，Read()遇EAGAIN时挂起G而非返回错误，由netpoller监听就绪后唤醒G，全程对用户透明。
Go 的网络服务在 Linux 下默认就是基于 epoll + 非阻塞 I/O 实现的，但 Go 并不让你直接操作 epoll，而是通过 netpoll 抽象层把事件监听、Goroutine 挂起/唤醒全包圆了。你写的是同步风格的 conn.Read()，底层却是事件驱动——这不是“封装得漂亮”，而是 runtime 强制介入的结果。
为什么 Go net.Conn 默认是非阻塞的，却从不返回 EAGAIN/EWOULDBLOCK？
因为 Go runtime 在创建 socket 时就调用了 fcntl(fd, F_SETFL, O_NONBLOCK)，并把 fd 注册进 epoll 实例；当你调用 Read() 时，如果内核接收缓冲区为空，runtime 不会把错误抛给用户代码，而是立刻把当前 Goroutine 挂起，并注册读就绪事件到 netpoll。等 epoll_wait 返回该 fd 可读，调度器才唤醒 Goroutine 继续执行——整个过程对开发者透明。
- 你永远看不到
EAGAIN，是因为错误被 runtime 吞掉了，换成了 Goroutine 调度行为 - 如果你手动用
syscall.Syscall调用read()原生系统调用，反而会遇到EAGAIN，因为绕过了 net 包的封装 - 这种设计让开发者不用写轮询逻辑，但也意味着无法用
select{ case 直接监听一个 raw fd 的就绪状态（除非用 <code>runtime.Netpoll底层接口）
epoll_wait 返回后，Go 是怎么找到对应 Goroutine 并唤醒的？
关键在 netpoll 和 gopark / goready 的协作。每个被挂起的网络 Goroutine 都会在其 G 结构体里记录等待的 fd 和事件类型（如 netpollReadDeadline），同时把自身指针存入该 fd 对应的等待队列（由 struct pollDesc 管理）。当 epoll_wait 返回一批就绪 fd，netpoll 会遍历这些 fd，取出各自关联的 pollDesc，再从里面取出等待中的 G 列表，逐个调用 goready 标记为可运行。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 这个映射关系不是哈希表或全局 map，而是每个
pollDesc直接嵌在fd对应的运行时结构中，避免查找开销 - 唤醒不是立刻执行，而是放入 P 的本地运行队列，等调度器下一次调度轮到它
- 如果设置了读写超时，
netpoll还要维护一个最小堆来管理定时器，和就绪事件一起被epoll_wait的 timeout 参数协调
你能绕过 netpoll 直接用 epoll_ctl 吗？能，但代价很高
可以，比如用 syscall.EpollCreate1、syscall.EpollCtl 手动管理 fd，再用 runtime.Entersyscall / runtime.Exitsyscall 告诉调度器“我要进系统调用了”。但这么做会破坏 Go 的网络模型契约：
- 你注册的 fd 不会被
netpoll管理，conn.SetReadDeadline()对它无效 - 如果在
epoll_wait阻塞期间发生 GC STW，Go 无法安全暂停你的系统调用，可能触发entersyscallblock报警 - 更严重的是：一旦你在回调里启动新 Goroutine 去处理数据，它和你手写的 epoll 循环不在同一调度上下文中，容易出现竞态或资源泄漏
真正需要精细控制 epoll 行为的场景（比如实现自定义协议栈、零拷贝收发），通常会用 CGO 调用 C 层 epoll 循环，再通过 channel 或 runtime.Goexit 与 Go 层桥接——而不是在纯 Go 里硬刚 epoll_ctl。net 包的设计哲学很明确：你要么全用它，要么彻底离开它。
