C#在Windows下无法实现真正零拷贝DMA传输；TransmitFile是其最接近零拷贝的方案，需P/Invoke调用且仅适用于未加密TCP socket。
Windows平台下C#能否绕过内核缓冲区直接DMA传输文件
不能。C#（乃至整个.NET运行时）本身不提供用户态直接控制DMA或绕过内核页缓存的接口。Zero-copy在严格意义上要求数据不经过CPU拷贝、不进入用户空间缓冲区，而Windows的I/O模型（即使是FILE_FLAG_NO_BUFFERING）仍需经过内核I/O管理器和存储驱动栈，无法跳过内核空间。
使用MemoryMappedFile是否算Zero-Copy
不算，但可显著减少内存拷贝次数。它通过映射文件到进程虚拟地址空间，避免了Read/Write调用中的用户-内核缓冲区拷贝，但底层仍依赖系统页表管理和缺页中断，数据实际流动仍经由内核缓存（除非配合FILE_FLAG_NO_BUFFERING + 对齐I/O）。常见误用点：
-
MemoryMappedFile默认仍走系统缓存，需显式传入HandleOptions.None并确保文件句柄以FILE_FLAG_NO_BUFFERING打开（且读写偏移/长度/缓冲区地址均按扇区对齐，通常是512字节或4KB） - .NET 6+ 的
MemoryMappedFile.CreateFromFile(..., pageFaults: false)仅影响映射行为，不改变I/O路径 - 跨进程共享映射时，若另一端是原生代码并使用
WSASendFile或TransmitFile，才可能触发内核级零拷贝发送（如TCP栈直接从文件缓存取数）
接近Zero-Copy的可行路径：用TransmitFile + P/Invoke
这是Windows上最接近零拷贝的方案——让内核直接把文件数据从缓存送入TCP socket，全程不经过用户空间。C#需通过P/Invoke调用TransmitFile：
[DllImport("kernel32.dll", SetLastError = true)]
static extern bool TransmitFile(
IntPtr hSocket,
IntPtr hFile,
uint nNumberOfBytesToWrite,
uint nNumberOfBytesPerSend,
IntPtr lpOverlapped,
IntPtr lpTransmitBuffers,
uint dwReserved);
关键约束：
- 目标socket必须是已连接的TCP套接字，且启用
SO_SNDBUF=0（禁用发送缓冲）效果更佳 -
hFile须以FILE_FLAG_SEQUENTIAL_SCAN打开，提升预读效率；FILE_FLAG_NO_BUFFERING反而可能导致失败（TransmitFile内部依赖系统缓存） - 不能用于TLS/SSL socket——加密必须发生在用户态，必然触发拷贝
- .NET的
NetworkStream和TcpClient不暴露底层socket句柄控制权，需用Socket类并保持非托管句柄有效
为什么Span<byte>或ReadOnlyMemory<byte>不等于Zero-Copy
它们只是避免了数组分配和边界检查开销，本质仍是用户态内存视图。若你用FileStream.Read(Span<byte>)，数据依然从内核缓冲区复制到该Span指向的托管堆或栈内存中。真正零拷贝意味着：没有一次memcpy调用发生在用户代码可见路径上，而.NET所有托管I/O API都隐含这一步。
如果追求极致吞吐，重点不在“避免拷贝”，而在“减少上下文切换和系统调用次数”——比如批量读取+IOCP完成端口，比纠结单次Zero-Copy更实际。Windows的FILE_FLAG_NO_BUFFERING + 直接I/O + 对齐访问，虽不是零拷贝，但能绕过系统缓存污染，对大文件顺序读写反而更稳。
