io.Copy按splice→sendfile→read/write顺序试探零拷贝：仅当src为os.File、dst为裸net.TCPConn、内核≥2.6.33（sendfile）或≥4.5（splice）、fd同挂载命名空间时才可能生效；HTTP场景因ResponseWriter封装必降级为read/write。
io.Copy 什么时候会调用 sendfile 或 splice
它不会“默认”零拷贝，而是按固定顺序试探：先尝试 splice，失败再试 sendfile，全都不行才降级为 read+write。能否触发，完全取决于你传进去的 src 和 dst 类型：
- 源必须是
*os.File（普通磁盘文件、pipe），不能是bytes.Buffer、strings.Reader或任何包装过的io.Reader - 目标必须是实现了
WriterTo的类型，比如裸*net.TCPConn；http.ResponseWriter、bufio.Writer、tls.Conn全部不支持 - Linux 内核需 ≥ 2.6.33（
sendfile）或 ≥ 4.5（splice对 regular file 的支持） - 挂载选项含
noatime，且两个 fd 在同一挂载命名空间（Docker/K8s 中常因容器隔离失效）
如何验证底层到底走了哪条路径
别猜，直接看系统调用：
- 运行
strace -e trace=sendfile,splice,read,write ./your-binary - 只看到
sendfile或splice调用 → 成功走零拷贝 - 混着出现
read和write→ 已降级，数据正被搬进搬出用户态缓冲区 - 注意：HTTP 场景下几乎必然看到
read/write，因为http.ResponseWriter拦在中间，io.Copy根本触不到 socket fd
file.WriteTo(conn) 是更可靠的零拷贝入口
io.Copy 是通用适配器，而 *os.File.WriteTo 是专为零拷贝设计的窄接口。它在满足条件时自动调用 sendfile，失败则安全 fallback 到 io.Copy：
- 源：必须是
*os.File，且以os.O_RDONLY打开（/proc、pipe、设备文件不行） - 目标：必须是未被包装的
*net.TCPConn，绝不能是http.ResponseWriter或tls.Conn - 提取 fd 时别用
conn.(*net.TCPConn).File()—— 这会提前关闭连接；要用conn.(*net.TCPConn).SyscallConn()配合Control() - 示例：
fd, _ := os.Open("data.bin"); fd.WriteTo(conn)，其中conn是裸 TCP 连接
为什么 http.ServeContent 比手写更稳
它不是“魔法”，而是把零拷贝条件封装成可检查、可 fallback 的 HTTP 协议层逻辑：
立即学习“go语言免费学习笔记（深入）”；
- 要求源实现
io.ReadSeeker+Stat()（*os.File满足，但加密流或io.MultiReader包装后就不行） - 必须显式设置
w.Header().Set("Content-Disposition", "attachment; filename=xxx")，否则浏览器可能尝试渲染而非下载 - 必须传入准确的
modtime（如fi.ModTime()），否则缓存逻辑失效，甚至退化为完整响应 - 内部自动处理 Range、ETag、304 等，满足条件就直通
sendfile，否则 fallback 到带缓存的io.Copy
真正容易被忽略的是：零拷贝路径极其脆弱，一次 TLS 封装、一个 bufio.Writer 包装、甚至 Docker 容器挂载方式不对，都会让它静默降级。与其反复调试 syscall，不如先确认你是否真的需要绕过协议层 —— 大多数吞吐瓶颈其实在缓冲区复用和 GC 压力上。
