io.Copy并非零拷贝，仅自动选择高效路径；真零拷贝需用syscall.Splice等系统调用绕过用户态内存拷贝，且受限于fd类型与平台。
Go 里 io.Copy 默认不是零拷贝
很多人以为 io.Copy 是零拷贝，其实它只是“自动选择高效路径”，底层仍可能触发用户态内存拷贝。真正零拷贝必须绕过 Go 的 runtime 内存管理，直通操作系统提供的能力，比如 sendfile 或 splice 系统调用。
常见错误现象：io.Copy 在大文件传输时 CPU 飙高、吞吐上不去，但 strace 显示大量 read+write 调用——这说明数据正被反复搬进搬出用户缓冲区。
- Linux 下优先用
syscall.Sendfile（需源是文件描述符，目标是 socket） - Go 1.21+ 可用
io.CopyN+net.Conn.SetWriteBuffer配合，但仍是用户态拷贝，不算真零拷贝 -
os.File.ReadAt+conn.Write组合看似可控，实则每次Write都会复制到内核 socket 缓冲区，无法避免
Linux splice 是 Go 零拷贝最可行路径
splice 能在内核态直接把管道（pipe）一端的数据“搬”到 socket 或另一管道，全程不经过用户内存。Go 没有原生封装，得自己调 syscall.Splice，而且必须满足两个条件：至少一端是 pipe，且两端都支持 splice（如普通文件不行，/dev/null 不行，socket 和 pipe 可以）。
使用场景：HTTP 文件服务中，从磁盘读取再发给客户端；或代理中转发上游响应体。
立即学习“go语言免费学习笔记（深入）”；
- 先用
syscall.Pipe2创建一对 pipe fd - 用
syscall.Splice把文件 fd → pipe[1]，再 pipe[0] → conn.fd - 注意
splice返回值是实际搬运字节数，要循环直到读完，别只调一次 - Go 的
net.Conn没暴露底层 fd？可以用conn.(*net.TCPConn).SyscallConn()获取
unsafe.Slice 和 reflect.SliceHeader 不等于零拷贝
有人想用 unsafe.Slice 把文件 mmap 内存直接转成 []byte，再传给 conn.Write——这是危险误区。即使绕过了分配，Write 方法内部仍会复制数据到内核 socket 缓冲区，mmap 地址只是起点，不是通路。
性能影响明显：mmap + unsafe 转 slice 后写 socket，比直接 io.Copy 还慢，因为多了 page fault 和 TLB 压力，且没省掉那一次用户态拷贝。
- 除非你后续用
syscall.Sendfile或splice，否则 mmap 本身不构成零拷贝链路 -
reflect.SliceHeader手动构造 header 容易触发 panic（如 len > cap），Go 1.21 后更严格，运行时会校验 - CGO 方案（如调用 C 的
sendfile）可行，但失去跨平台性，且需处理 errno 和中断重试逻辑
HTTP 服务中零拷贝的现实边界
哪怕系统调用层面做到了零拷贝，HTTP 协议栈本身就有开销：header 构造、chunked 编码、TLS 加密——这些全在用户态，必然涉及内存操作。所以“零拷贝”只适用于 body 数据流，且仅当 client 支持 HTTP/1.1 keep-alive 或 HTTP/2 流控时才值得投入。
容易踩的坑：
- 用
http.ServeFile？它内部就是io.Copy，不是零拷贝 - 用
http.FileServer？同上，还多一层 os.Stat 和 MIME 推断 - 启用
conn.SetNoDelay(true)对零拷贝没帮助，那是控制 Nagle 算法的 - Go 的
net/httpserver 默认复用 buffer，但复用的是用户态 buffer，和零拷贝无关
真正在生产环境压榨零拷贝，往往要放弃标准库 http server，改用 gnet 或手写基于 epoll + splice 的裸 TCP 服务——这时候，零拷贝才从概念变成可测的延迟与吞吐数字。
