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></byte>
或ReadOnlyMemory<byte></byte>
不等于Zero-Copy
它们只是避免了数组分配和边界检查开销，本质仍是用户态内存视图。若你用
FileStream.Read(Span<byte>)</byte>，数据依然从内核缓冲区复制到该
Span指向的托管堆或栈内存中。真正零拷贝意味着：没有一次
memcpy调用发生在用户代码可见路径上，而.NET所有托管I/O API都隐含这一步。
如果追求极致吞吐，重点不在“避免拷贝”，而在“减少上下文切换和系统调用次数”——比如批量读取+IOCP完成端口，比纠结单次Zero-Copy更实际。Windows的
FILE_FLAG_NO_BUFFERING+ 直接I/O + 对齐访问，虽不是零拷贝，但能绕过系统缓存污染，对大文件顺序读写反而更稳。
