go原生不支持io_uring，因runtime基于epoll和同步系统调用，未接入该接口；gouring库通过纯go实现协议层（含unsafe内存操作、原子索引控制、syscall6调用），规避cgo但放弃内存安全，需严格满足2的幂entries、o_direct优化、buffer生命周期锁定等条件才能真正发挥性能。
Go 语言原生不支持 io_uring，因为 runtime 的网络轮询器（netpoll）和文件 I/O 都基于 epoll + 同步系统调用封装，并未接入内核的 io_uring 接口。想在 Go 中真正用上 io_uring，必须绕过 CGO 或依赖外部库——但关键在于：**不是所有“支持 io_uring”的 Go 库都等于“零拷贝、全异步、无 runtime 干预”**。
为什么直接用 syscall/io_uring 不行？
Go 的 syscall 包只暴露了基础系统调用，而 io_uring 初始化需要三步原子协作：io_uring_setup → mmap 映射 SQ/CQ 内存 → 用返回的 ring_fd 配合 io_uring_enter 提交。Go 运行时会拦截并重定向部分 fd 操作（尤其是涉及 epoll_ctl 或 close 时），若手动管理 ring_fd 且未正确隔离，极易触发 runtime: bad mlock of address 或静默丢事件。
- Go 的
runtime默认将所有文件描述符注册进epoll实例，ring_fd被误加入后会导致内核通知混乱 -
mmap映射的 ring 内存若未用unsafe精确对齐（如sq_off.head偏移需 4 字节对齐），读写索引会越界或卡死 - 没有
liburing的io_uring_get_sqe这类安全封装，裸操作SQ Array容易覆盖未提交的sqe
gouring 库为何能“无 CGO”却仍可靠？
gouring 不是魔法，它用纯 Go 实现了 io_uring 协议层：自己解析 io_uring_params、手写 ring 索引递增逻辑、用 sync/atomic 控制 tail 提交边界，并显式调用 syscall.Syscall6 触发 io_uring_enter。它规避了 CGO，但代价是放弃 Go 的内存安全模型——所有 ring 结构体字段访问都通过 unsafe.Pointer + 偏移计算。
- 初始化时传入的
entries必须是 2 的幂（如 256、512），否则ring_mask计算错误导致索引溢出 -
gouring.PrepWrite内部硬编码了sqe.opcode = IORING_OP_WRITE和sqe.flags = 0，不支持IOSQE_IO_LINK等链式操作 - 调用
SubmitAndWait(n)时，若n > available SQE 数量，库不会阻塞等待空闲条目，而是直接 panic —— 这和liburing的io_uring_submit_and_wait行为不一致
实际文件读写中容易被忽略的陷阱
哪怕用了 gouring，文件 I/O 在 io_uring 下仍有特殊约束。最典型的是：**普通文件读写默认走 page cache，而 io_uring 的高性能路径依赖 O_DIRECT 或预注册 buffer**。
- 不加
O_DIRECT时，IORING_OP_READ仍可能因 page fault 触发同步阻塞，失去异步意义 -
gouring的PrepRead要求传入*byte地址，但 Go 的 slice 底层内存可能被 GC 移动；必须用runtime.KeepAlive锁住生命周期，否则内核读到野指针 - Linux 5.19+ 才支持
IORING_SETUP_IOPOLL模式下对普通文件的轮询，旧内核开启该 flag 会导致io_uring_setup返回EINVAL
真正把 io_uring 文件 I/O 推到极限，得同时控制三个层面：内核参数（/proc/sys/vm/dirty_ratio）、用户 buffer 生命周期（避免 GC 干扰）、以及 ring 提交节奏（避免 CQ 溢出）。少一个，就只是“看起来用了 io_uring”，而不是“真正榨干了它”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
