零拷贝技术中数组不是工具而是待消除的中间层，其存在标志数据滞留用户态并引发冗余拷贝；真正起作用的是内核的Page Cache、SG-DMA和VMA等机制，通过sendfile等系统调用绕过用户缓冲区实现高效传输。
零拷贝技术中没有“数组”作为独立角色参与传输，它不依赖用户定义的数组变量来完成数据搬运。所谓“数组”，在传统 read/write 流程里只是用户态缓冲区的一种常见表现形式（比如 char buf[4096]），但恰恰是这个缓冲区及其背后的数据拷贝动作，成了零拷贝要绕开的关键环节。
用户态数组其实是性能瓶颈的载体
在标准文件发送流程中，用户声明的数组（如 read(fd, buf, size) 中的 buf）承担了两个本可省略的职能：
- 充当内核态数据的临时落脚点，引发一次 CPU 拷贝（内核 buffer → 用户 buf）
- 成为 write 系统调用的输入源，又触发一次 CPU 拷贝（用户 buf → socket buffer）
这两次拷贝与数组存在强绑定——只要数据必须经由该数组中转，零拷贝就无法成立。因此，优化方向不是“怎么让数组更快”，而是“如何让数据完全不经过这个数组”。
真正起作用的是内核内部的数据结构
零拷贝生效的核心，是内核利用自身已有机制跳过用户态中转，直接操作底层资源：
- Page Cache：文件读取时，数据已缓存在内核页缓存中，无需重复加载
- Socket Buffer + SG-DMA：sendfile 在 2.4+ 内核中可将 Page Cache 地址直接交给网卡驱动，由 DMA 控制器按段（scatter-gather list）直接读取并发送
- VMA（虚拟内存区域）：mmap 将文件映射为进程地址空间的一段虚拟内存，访问时触发缺页异常，内核直接关联 Page Cache 页面，避免拷贝
这些结构都运行在内核态，不暴露给用户代码，也不以“数组”形式存在，而是通过指针、描述符、页表项等机制完成高效衔接。
开发者需要关注的不是数组本身，而是数据路径控制权
能否启用零拷贝，取决于你是否把数据流的控制权交还给内核：
- 用
read + write：你强制数据流经用户数组 → 四次拷贝 - 用
mmap + write：你放弃对内容的直接访问需求，让内核管理映射 → 减少一次 CPU 拷贝 - 用
sendfile：你只提供源文件 fd 和目标 socket fd，其余全由内核调度 → 最小化上下文切换与拷贝
此时，用户代码里甚至可以不声明任何缓冲数组——sendfile 调用本身就不需要 buf 参数。
小结：数组不是工具，而是待消除的中间层
在零拷贝语境下，“数组”不是被优化的对象，而是被规避的对象。它的存在标志着数据仍在用户态滞留，意味着额外拷贝和上下文切换尚未被消除。真正的优化发生在内核内部——通过复用 Page Cache、委托 DMA、合并系统调用等方式，让数据在内核可控范围内直达目的地。写 C++ 服务时，优先选用 sendfile 或 splice，比纠结 buf 大小更能释放性能红利。
