go中零拷贝需满足内核≥2.6.33、源为os.file且只读、目标为未包装的net.tcpconn、fd有效且非阻塞；file.writeto是唯一安全出口，http.servefile因用io.copy且封装responsewriter而无法零拷贝。
Go 语言里没有“调个函数就零拷贝”的捷径。真正在传输路径上省掉用户态内存拷贝，必须满足内核能力、fd 类型、连接状态三重严苛条件；绝大多数人写的 io.Copy 或 http.ServeFile 都在做四次拷贝中的两次 CPU 参与操作，CPU 飙高、吞吐卡在 100MB/s 以下就是典型信号。
file.WriteTo(conn) 什么时候真正走 sendfile？
这是 Go 标准库中唯一可能触发零拷贝的“安全出口”，但它不是 always-on 开关，而是带条件的 fallback：
- 源必须是
*os.File，且用os.O_RDONLY打开；/proc、pipe、tls.Conn、bytes.Buffer全部不认 - 目标必须是未被包装的
*net.TCPConn；http.ResponseWriter、bufio.Writer、tls.Conn会直接降级为io.Copy - 连接 fd 必须有效，且不能处于 hijacked 后又手动 close 的状态（
conn.(*net.TCPConn).File()会提前关闭底层 fd） - Linux 内核 ≥2.6.33，socket 设为非阻塞更稳妥（避免 sendfile 卡住 M 线程）
验证是否生效：运行 strace -e trace=sendfile,read,write ./your-binary。只看到 sendfile 调用，才算成功；混有 read/write 就说明已 fallback。
为什么 http.ServeFile 永远不零拷贝？
它内部用的是 io.Copy，不是 file.WriteTo。哪怕你传入一个普通文件，也绕不开用户缓冲区中转：
-
http.ResponseWriter是带 buffer 的封装体，Write方法必然触发一次用户态到 socket 缓冲区的拷贝 - 它还要处理 header、自动计算
Content-Length、ETag、If-Modified-Since等逻辑，全部在用户态完成 - 即使文件很小，也逃不过四次拷贝中的两次 CPU 参与环节
想在 HTTP 场景用零拷贝，得手动 hijack：w.(http.Hijacker).Hijack() 拿到原始 net.Conn，再调 file.WriteTo(conn)。但要注意：Hijack 后你得自己管理 connection 关闭、超时、keep-alive 头、CRLF 换行、Content-Type 设置——漏一条，客户端就收不到完整响应。
代理场景下只能靠 syscall.Splice 拼路径
当你需要把上游 HTTP 响应体（比如从另一个服务读来的 io.Reader）直接转发给下游客户端，io.Copy 必然失败——因为上游不是 *os.File，WriteTo 根本不可用。此时唯一可行的零拷贝路径是 syscall.Splice：
- 先用
syscall.Pipe2创建一对 pipe fd - 用
syscall.Splice把上游 conn 的读端 →pipe[1]（注意：上游 conn 必须支持 splice，如*net.TCPConn可以，tls.Conn不行） - 再用
syscall.Splice把pipe[0]→ 下游 conn.fd -
splice返回值是实际搬运字节数，要循环直到读完，别只调一次
splice 要求至少一端是 pipe，且两端都支持 splice（socket 和 pipe 可以，普通文件不行，/dev/null 不行）；跨 mount point（如不同文件系统）可能失败；目标 socket 必须是非阻塞，否则可能卡住。
手写 syscall.Sendfile 容易翻车的硬坑
别被“系统调用”四个字骗了——它比 io.Copy 脆弱得多，出错成本高，且几乎无法调试：
-
unix.Sendfile(outfd, infd, offset, count)参数顺序和 C 原型相反，offset是指针地址，Go 里得传&offset，漏掉就 panic - 必须用
conn.(*net.TCPConn).SyscallConn()获取原始 fd，再调Control()进系统调用；conn.(*net.TCPConn).File()会提前关掉连接，后续conn.Write直接 panic -
Sendfile不感知 Go 的 goroutine 抢占——若内核卡住（比如磁盘慢、网络拥塞），整个 M 线程会被锁死，拖垮调度器 - 返回值是
(int64, errno)，不能只看err == nil就认为成功——要检查实际返回字节数是否等于预期，否则可能是 partial write
真正值得投入的优化点不在“有没有调用 splice”，而在缓冲区复用、内存池管理、协议层设计上。零拷贝路径天然不可移植（Windows 没 sendfile，macOS 的变种不支持 socket → socket），硬上 syscall 很难维护。优先依赖 file.WriteTo(conn)，它已在 runtime 层做了平台适配和降级兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
