为什么 io.Copy 默认不是零拷贝？
因为 io.Copy 底层走的是用户态缓冲区中转：数据从内核读到 Go 的 buf（默认 32KB），再写回内核。两次上下文切换 + 一次内存拷贝，不是真正零拷贝。
真正的零拷贝必须绕过用户态内存拷贝，让数据在内核空间直接流转。Go 本身不提供裸 sendfile 或 splice 封装，但可通过系统调用或特定组合逼近。
- Linux 下
sendfile(2)支持文件 → socket 直传（无用户态拷贝），但 Go 标准库没暴露该能力 -
net.Conn实现（如net.TCPConn）内部支持WriteTo方法，部分场景会自动触发sendfile - 关键前提：源必须是
*os.File，目标必须是支持WriteTo的net.Conn，且文件需支持mmap（普通磁盘文件 OK，/proc或 pipe 不行）
file.WriteTo(conn) 能否触发零拷贝？
能，但有严格条件。Go 1.16+ 在 Linux 上对 *os.File 的 WriteTo 做了优化：若目标 conn 是 *net.TCPConn 且底层 fd 有效，会尝试调用 sendfile 系统调用。
失败时自动 fallback 到普通 io.Copy，所以行为是安全的，但你得确认它真跑起来了。
立即学习“go语言免费学习笔记（深入）”；
- 检查是否生效：用
strace -e trace=sendfile,write,read运行程序，看到sendfile调用即成功 - 文件必须已打开为只读（
os.O_RDONLY），且不能是管道、socket、设备文件 - 目标连接不能被包装（比如套了
bufio.Writer或 TLS 连接 ——tls.Conn不实现WriteTo，会降级） - 示例：
fd, _ := os.Open("large.bin")<br>fd.WriteTo(conn) // conn 是 *net.TCPConn，未被包装
为什么 http.ServeFile 不一定零拷贝？
它内部用的是 io.Copy，不是 file.WriteTo。即使你传入普通文件，只要用了 http.ResponseWriter（本质是包装过的 bufio.Writer），就无法触发 sendfile。
想在 HTTP 服务里用零拷贝，得自己构造响应流，绕过标准 handler 流程。
- 手动设置
Content-Length和Content-Type - 调用
w.(http.Hijacker).Hijack()拿到原始net.Conn，再用file.WriteTo(conn) - 注意：Hijack 后要自己处理 connection 关闭、超时、keep-alive 逻辑，HTTP/2 不支持 Hijack
- 更稳妥的做法：用
golang.org/x/net/http2/h2c或直接上fasthttp（其Ctx.SendFile显式调用sendfile）
跨平台兼容性与 fallback 必须考虑
Windows 没有 sendfile，macOS 只有 sendfile 的受限版本（不支持 socket → socket），所以零拷贝路径天然不可移植。
别硬写条件编译去调用 syscall，Go 官方明确不鼓励直接 syscall 驱动网络传输 —— 容易出错且难维护。
- 优先依赖
file.WriteTo(conn)，它已在 runtime 层做了平台适配和降级 - 用
reflect.ValueOf(conn).MethodByName("WriteTo").IsValid()动态判断是否支持（实际不推荐，改用接口断言更清晰） - 真实线上服务中，90% 的吞吐瓶颈不在拷贝，而在磁盘 I/O 或网络带宽；先用
pprof确认runtime.readnext或syscall.Syscall是否真占 CPU 高峰
零拷贝不是银弹。它只在大文件 + 高并发 + 内核支持 + 连接未被包装这几个条件同时满足时才明显见效。漏掉任意一环，代码就退化成普通拷贝，还可能引入隐蔽的连接管理 bug。
