file.writeto(conn) 未走零拷贝是因为其触发需满足严格条件：源必须为只读打开的os.file，目标必须为未包装的net.tcpconn且fd有效非阻塞，否则降级为io.copy。
file.WriteTo(conn) 为什么没走零拷贝
它不是默认开启的开关，而是带条件的 fallback —— 源必须是 *os.File 且用 os.O_RDONLY 打开；目标必须是未被包装的 *net.TCPConn；连接 fd 必须有效且非阻塞。任意一环不满足，就会悄悄降级为 io.Copy，你看到的仍是 read + write 系统调用。
常见错误现象：
-
http.ResponseWriter被传给file.WriteTo—— 它不实现WriteTo，直接 fallback - 用
bufio.NewWriter(conn)包了一层再传 ——WriteTo方法被覆盖，无法穿透 - 文件是从
/proc、pipe或bytes.Buffer构造的 —— 这些类型不支持sendfile
如何验证 sendfile 是否真正生效
别靠猜，用 strace 直接看系统调用：
strace -e trace=sendfile,read,write ./your-binary
只看到 sendfile 调用，且返回值等于文件大小，才算成功；一旦混入 read 或 write，说明已 fallback 到用户态搬运。
注意点：
- Linux 内核需 ≥2.6.33（主流发行版基本满足）
- socket 必须设为非阻塞：
conn.(*net.TCPConn).SetNonblock(true)，否则卡住 M 线程 - 不要在
defer fd.Close()后调file.WriteTo——conn.(*net.TCPConn).File()会提前关闭底层 fd
HTTP 场景下想用零拷贝，绕不开 Hijack
http.ServeFile 永远不会走零拷贝，因为它用的是 io.Copy + 封装过的 ResponseWriter，header、ETag、CRLF 全在用户态处理。
真要提速，得手动 hijack：
- 先断言
w.(http.Hijacker).Hijack()拿到原始net.Conn - 自己写 status line 和 headers：
"HTTP/1.1 200 OK\r\nContent-Length: ...\r\nContent-Type: ...\r\n\r\n" - 再调
fd.WriteTo(conn)—— 注意：fd是*os.File，不是conn - 后续所有 connection 生命周期管理（超时、keep-alive、关闭）都得自己写，漏一条客户端就收不到完整响应
HTTP/2 不支持 Hijack，TLS 连接也无法穿透 —— 这条路径只适用于 HTTP/1.1 明文服务。
别硬上 syscall.Sendfile，除非你清楚三颗雷在哪
手写 syscall.Sendfile 看似直接，但实际极易翻车：
- 参数顺序和 C 原型相反：
Sendfile(outfd, infd, &offset, count)，&offset漏了就 panic -
conn.(*net.TCPConn).File()会关闭连接，后续任何conn.Write都 panic - 失败时不重试
EAGAIN、不处理EINTR，容易丢数据
更隐蔽的问题是：它不感知 goroutine 抢占 —— 若磁盘慢或网络拥塞，整个 M 线程会被锁死，拖垮调度器。真正值得投入的优化点，往往不在“有没有调 sendfile”，而在缓冲区复用、帧协议设计、以及避免不必要的协议封装。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
