io.copy快慢取决于是否触发零拷贝：先试splice，再试sendfile，均失败才降级为read+write；仅当src为*os.file、dst为裸net.conn且满足内核版本、挂载命名空间等严苛条件时才生效。
io.Copy 为什么有时快、有时慢
它不是靠“智能判断”选路径，而是按固定顺序试探零拷贝能力：先试 splice，失败再试 sendfile，全都不行才退化为用户态缓冲区循环 read+write。快慢完全取决于你传的 src 和 dst 类型是否满足底层系统调用约束。
-
src必须是*os.File（普通磁盘文件），不能是bytes.Buffer、strings.Reader或任何包装过的io.Reader -
dst必须实现WriterTo接口且未被封装——裸*net.TCPConn可以，http.ResponseWriter、bufio.Writer、tls.Conn全部不行 - Linux 内核需 ≥ 4.5（
splice对 regular file 支持）或 ≥ 2.6.33（sendfile） - 两个 fd 必须在同一挂载命名空间（Docker/K8s 中常因容器 rootfs 隔离失效）
怎么确认 io.Copy 到底走了哪条路径
别猜，直接看系统调用：
strace -e trace=sendfile,splice,read,write ./your-binary
如果只看到 sendfile 或 splice 调用 → 成功走零拷贝；如果混着出现 read 和 write → 已降级，数据正被搬进搬出用户态缓冲区。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- HTTP 场景下几乎必然看到
read/write，因为http.ResponseWriter拦在中间，io.Copy根本触不到 socket fd - 想绕过这个限制，得手动提取裸连接：
conn.(*net.TCPConn).SyscallConn()+Control()，再传给file.WriteTo(conn) -
file.WriteTo(conn)是比io.Copy更可靠的零拷贝入口——它专为此设计，失败时自动 fallback 到io.Copy
为什么 http.ServeContent 比手写 io.Copy 更稳
它不是魔法，而是把零拷贝条件封装成可检查、可 fallback 的 HTTP 协议层逻辑：
- 源必须实现
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
常见错误：复制完目标文件为空或权限丢失
io.Copy 只搬运字节，不打开、不关闭、不创建文件，也不复制元信息。
- 目标文件为空，基本就三种情况：
os.Open错误用于写入（只读 panic）、os.Create没成功（路径不存在或权限不足）、漏掉dst.Close()导致缓冲区未刷盘 - 权限、修改时间、访问时间全丢——生产环境必须补：
dst.Chmod(info.Mode())+os.Chtimes(dst, info.Atim(), info.Mtim()) - 别用
bytes.Buffer中转大文件，整文件进内存，极易 OOM；也别手动套bufio.Reader/bufio.Writer，缓冲区叠加可能死锁或延迟写入
真正容易被忽略的是挂载命名空间和 fd 提取方式：conn.(*net.TCPConn).File() 会提前关闭连接，必须用 SyscallConn().Control()；而 Docker/K8s 中的 rootfs 隔离，常常让两个 fd 不在同一个挂载命名空间里，splice 直接失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
