Linux下真正的Zero-Copy仅在满足严格条件时可用：sendfile()要求源为普通文件、目标为socket；splice()需至少一端为pipe或内核≥5.17且配置支持；二者均无法完全避免拷贝，仅减少CPU参与。
Zero-Copy 在用户态文件传输中无法真正“零拷贝”——Linux 下 sendfile() 和 splice() 能绕过用户缓冲区，但必须配合 socket 套接字且受限于文件描述符类型和内核版本；C++ 自己用 read()/write() 或 std::ifstream + boost::asio::async_write 必然触发至少一次内核到用户态的数据拷贝，所谓“C++ 实现 Zero-Copy”本质是选对系统调用、减少拷贝次数，而非消灭拷贝。
什么时候能用真正的 Zero-Copy 系统调用？
只有满足全部条件时，sendfile() 或 splice() 才可能不经过用户内存：
-
sendfile()：源 fd 必须是普通文件（不能是 pipe、socket、/dev/zero），目标 fd 必须是 socket（且 socket 不能启用 TCP_NODELAY 以外的某些选项）；返回值为 -1 且errno == EINVAL就说明不支持 -
splice()：要求源或目标至少一个是 pipe（常用于fd → pipe → socket中转），但 pipe 容量有限（默认 64KB），需循环调用并检查返回值是否小于请求长度 - Linux ≥ 2.6.33 支持
splice()直连 file → socket（需SPLICE_F_MOVE | SPLICE_F_NONBLOCK），但实际兼容性差，glibc 封装不完善，建议优先测sendfile()
异步 I/O 下如何衔接 sendfile()？
sendfile() 是同步阻塞系统调用，不能直接丢进 boost::asio::io_context 或 io_uring 的异步队列。可行路径只有一条：用线程池 + sendfile() + 回调通知。
- 不要尝试用
io_uring_prep_sendfile()后直接投递——它仅在 kernel ≥ 5.17 且编译时启用CONFIG_IO_URING才稳定支持文件 fd；多数生产环境仍 fallback 到线程池 - 封装一个
async_sendfile(int out_fd, int in_fd, off_t* offset, size_t count)函数，内部用std::thread或线程池执行sendfile()，完成后通过post()把结果发回主线程 - 注意
off_t*参数必须指向堆上分配或长期有效的内存，因为线程可能比调用栈存活更久
为什么 mmap + writev 不等于 Zero-Copy？
有人用 mmap() 映射文件再调 writev() 多段发送，误以为避免了拷贝——其实 writev() 仍会把用户态 page fault 后的内存内容复制进 socket 发送队列，只是省去了 read() 这一步。
-
mmap()只是建立虚拟地址映射，真正访问时才发生缺页中断并加载数据；若文件大于物理内存，频繁换页反而拖慢吞吐 -
writev()的 iovec 数组最多支持IOV_MAX（通常 1024），大文件需分批，且每次调用仍有一次内核态拷贝 - 相比
sendfile()，它多了一次用户态地址空间管理开销，实测吞吐低 15%~30%
真正影响吞吐的不是“有没有拷贝”，而是“拷贝发生在哪、由谁触发、能否重叠”。sendfile() 把拷贝压给内核 DMA 引擎，CPU 几乎不参与；而任何用户态 memcpy 或 read/write 都要消耗 CPU 周期和 cache 带宽。别被“Zero-Copy”字面迷惑，先确认你的 fd 类型、内核版本、socket 配置，再决定要不要加线程池封装——否则写的越“高级”，跑得越慢。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
