C#无法直接使用io_uring，.NET Runtime未提供原生API；但.NET 6+的FileStream在Linux上满足条件时会自动启用io_uring后端。
io_uring 在 C# 中根本不能直接用
Linux 的 io_uring 是内核提供的底层异步 I/O 接口，C# 运行时（.NET Runtime）目前不提供任何原生封装或公开 API 让你直接提交 SQE、轮询 CQE 或管理 ring buffer。所有宣称“C# 支持 io_uring”的文章，要么混淆了概念，要么依赖第三方非官方绑定（如 IoUringSharp），但这些库仍处于实验阶段，不被 .NET 团队维护，也不进主线。
.NET 6+ 的 FileStream 在 Linux 上已悄悄用了 io_uring
真正起作用的是 .NET 运行时自己做的适配：从 .NET 6 开始，Linux 下的 FileStream 在满足特定条件时会自动降级到 io_uring 后端（通过 liburing 封装调用）。你不需要写任何特殊代码，但必须满足以下全部条件：
-
FileStream构造时传入isAsync: true（或使用File.OpenRead/Write等默认启用异步的工厂方法） - 文件系统支持
io_uring（ext4/xfs 通常 OK；overlayfs、某些 NFS 挂载点可能回退到 epoll） - 内核版本 ≥ 5.11（推荐 ≥ 5.16，修复了早期 ring 内存泄漏和信号竞争问题）
- 运行时编译时启用了
IOURING特性（.NET 官方二进制默认开启，自建 runtime 需确认）
验证是否生效？看 /proc/[pid]/fdinfo/[fd] 中是否有 io_uring 字样，或用 strace -e trace=io_uring_enter,io_uring_setup 观察系统调用。
别手动调 liburing 绑定 —— 兼容性和生命周期太坑
有人用 P/Invoke 调 liburing.so，看似自由，实则踩坑密集：
-
io_uringring buffer 内存需 pinned 且 page-aligned，.NET 的 GC 会移动托管内存，错位导致静默数据损坏 - 提交 SQE 后必须确保 buffer 在整个操作完成前不被回收 —— 手动
GCHandle.Alloc+pin极易漏释放，引发内存泄漏或访问违规 -
liburing版本碎片严重（v2.0 vs v2.3），不同发行版预装版本不一，struct io_uring_params字段偏移可能变化，P/Invoke struct 定义一错就崩溃 - .NET 的线程池调度和
io_uring的 completion queue 通知机制不直接对齐，容易写出阻塞回调或丢失完成事件
真要榨干性能？优先调优 FileStream + MemoryPool
99% 的高吞吐场景，靠改 runtime 参数比手撸 io_uring 更稳更有效：
- 设置环境变量
DOTNET_SYSTEM_IO_ENABLEIOURING=1（.NET 7+ 默认 true，但某些容器镜像可能关掉） - 用
MemoryPool<byte>.Shared.Rent()</byte>配合FileStream.ReadAsync(Memory<byte>, CancellationToken)</byte>，避免每次分配 buffer - 批量读写时用
FileStream.ReadAsync(ReadOnlyMemory<byte>, ...)</byte>而非Stream.ReadAsync(byte[], ...)，减少 span-to-array 转换开销 - 大文件顺序读写，关闭
FileStream的useAsync: false强制同步路径（反而更慢），也别设bufferSize小于 64KB ——io_uring最佳扇区对齐是 4KB，但 runtime 内部按 64KB 批量提交更高效
io_uring 不是银弹。它省掉的是 syscall 上下文切换，不是磁盘寻道或网络延迟。如果你的瓶颈在 SSD 延迟或网卡中断，再怎么绕过 epoll 也救不了。
