Windows上C#无法绕过内核做文件IO，因系统无io_uring或用户态驱动框架；所有IO均经NT内核栈，SPDK等需进程外服务+IPC实现。
Windows 上 C# 无法真正绕过内核做文件 IO
结论很直接：FileStream、MemoryMappedFile、甚至 Span<byte></byte> + NativeMemory 都走 Windows 内核 I/O 栈。所谓“旁路”在用户态 .NET 程序中不存在——不是写法问题，是系统设计限制。
Windows 没有像 Linux 那样的 io_uring 或用户态驱动框架（如 SPDK 的 NVMe 用户态驱动），也没有稳定公开的、供 .NET 直接调用的 kernel-bypass 存储接口。所有 CreateFile → ReadFile 调用最终都经由 NTFS/SMB/minifilter 层，无法跳过。
- 试图用
FileOptions.NoBuffering+FileOptions.WriteThrough只是绕过系统页缓存，不绕内核驱动栈 -
UnmanagedMemoryStream或NativeMemory.Allocate分配的内存仍需通过WriteFile提交，照样触发 IRP - 即使 P/Invoke
NtWriteFile，也只是换了个入口，底层仍是内核对象（FILE_OBJECT+DEVICE_OBJECT）
C# 调用 SPDK 的唯一可行路径：进程外 C/C++ 服务 + IPC
SPDK 是纯 C 实现、依赖轮询模式、绑定 CPU 核心、直接操作 NVMe 寄存器的用户态存储栈。它根本没提供 .NET 绑定，也不支持托管内存布局或 GC 堆上的 buffer。
想让 C# 应用“用上”SPDK，只能把它当独立服务跑，C# 通过轻量 IPC 对接：
- 推荐用 Unix domain socket（Windows 10 1803+ 支持）或命名管道（
\.pipespdk-proxy），避免序列化开销 - SPDK 侧用
spdk_nvme_ctrlr_submit_io_request处理读写，C# 侧只传逻辑块地址（LBA）、长度、buffer 地址（需提前注册为 SPDK 的spdk_dma_malloc内存） - 不能把
byte[]或Span<byte></byte>直接扔过去——SPDK 不认 GC 堆，必须用NativeMemory.Allocate+Marshal.Copy中转，且需在 SPDK 侧显式注册该内存段 - 性能瓶颈常卡在 IPC 序列化和跨进程拷贝；若追求极致，得用共享内存（
CreateFileMapping+MapViewOfFile），但需自己实现 ring buffer 协议
C#DPDK？不存在这个东西
DPDK 是 Linux 用户态网络栈，核心依赖 UIO 或 VFIO 驱动、hugepage、CPU 绑核、轮询收包——这些机制在 Windows 上要么没有，要么行为完全不同。
所谓 “C#DPDK” 是常见误解，实际只有两种可能：
- 有人用 C# 封装了 DPDK 的 C API（如通过
DllImport调rte_eal_init），但这只在 WSL2 下勉强可行，且 WSL2 的 network stack 本身已套了一层虚拟化，DPDK 性能归零 - 混淆了 “DPDK” 和 “数据平面开发” 概念，误把 .NET 的
SocketAsyncEventArgs或IOCP当成类似物——它们仍是内核 socket 接口，只是异步模型高效，不是 bypass - Windows 上等效方案是
NetAdapterCx+ 用户态 filter driver，但开发门槛极高，且 .NET 无法直接交互
真正值得投入的优化方向：别碰旁路，压榨现有栈
99% 的 C# 高吞吐文件场景，瓶颈不在内核，而在托管层设计或配置错误。
- 用
FileStream时禁用useAsync: true（.NET 6+ 默认开启），它会引入线程池调度开销；真要异步，用FileStream.ReadAsync+MemoryPool<byte>.Shared.Rent</byte>复用 buffer - 小文件随机读？关掉
FileOptions.RandomAccess反而更快——NTFS 元数据预读策略在某些 SSD 上负优化 - 大文件顺序写？确保
FileStream缓冲区 ≥ 1MB（bufferSize参数），并配合FileOptions.WriteThrough | FileOptions.NoBuffering（注意：NoBuffering 要求 offset/length 对齐 sector 边界） - 别信“零拷贝”宣传——.NET 中
ReadOnlyMemory<byte></byte>到磁盘仍是 copy，真正的 zero-copy 需硬件支持（如 NVMe ZNS + SPDK zcopy）和内核协作，C# 层不可见
绕过内核这事，不是加个 flag 或换个库就能成。它意味着放弃可移植性、牺牲调试能力、承担驱动级风险——而多数业务 IO 压力，其实卡在序列化、锁竞争或 GC 暂停上。先 profile，再决定要不要掀桌子。
