file.WriteTo(conn)是Go标准库中唯一可能触发sendfile零拷贝的路径，需满足源为os.O_RDONLY打开的os.File、目标为未包装的net.TCPConn且运行于Linux平台。
file.WriteTo(conn) 是唯一能触发 sendfile 的路径
Go 标准库里，真正可能走内核零拷贝（sendfile）的只有 file.WriteTo 这一个入口。它不是“可选优化”，而是唯一被 runtime 显式适配的零拷贝通道 —— 其他方式，包括 io.Copy、http.ServeFile、io.CopyBuffer，全部绕不过用户态缓冲区，必然发生内存拷贝。
能否生效取决于三个硬性条件：
-
*os.File必须以os.O_RDONLY打开，且不能是/proc、pipe、socket等不支持 mmap 的伪文件 - 目标
conn必须是未包装的*net.TCPConn（即底层 fd 有效，没套bufio.Writer、tls.Conn或http.ResponseWriter） - 运行平台需为 Linux（Windows/macOS 下自动 fallback 到
io.Copy）
用 strace -e trace=sendfile,write,read 跑程序，看到 sendfile 系统调用出现，才算真正启用。否则你写的“零拷贝”只是心理安慰。
http.ResponseWriter 不支持 WriteTo，别信 ServeFile
http.ServeFile 和 http.ServeContent 内部都走 io.Copy，哪怕你传的是普通磁盘文件，也绝不会触发 sendfile。因为 http.ResponseWriter 是个接口，实际类型通常是 *http.response，它不实现 io.WriterTo，也不暴露底层 conn。
立即学习“go语言免费学习笔记（深入）”；
想在 HTTP 场景用零拷贝，必须主动 hijack：
- 调用
w.(http.Hijacker).Hijack()拿到原始net.Conn - 手动设置
Content-Length、Content-Type和状态行（"HTTP/1.1 200 OK\r\n..."） - 直接调用
file.WriteTo(conn) - 自己处理连接关闭、超时、keep-alive 头逻辑（HTTP/2 完全不支持 hijack）
这不是“高级用法”，而是绕过标准 HTTP 流程的必要代价。用错一步，连接就卡死或返回乱码。
unsafe.String / unsafe.Slice 能省掉 string ↔ []byte 拷贝
当你要把大块二进制数据（比如从文件读出的 []byte）转成 string 传给模板、JSON 序列化或日志输出时，string(b) 会强制复制内存。在高频或大 payload 场景下，这开销可观。
若你确定该字节切片生命周期可控、且后续不会被修改，可用 unsafe 绕过拷贝：
func bytesToString(b []byte) string {
return *(*string)(unsafe.Pointer(&b))
}
func stringToBytes(s string) []byte {
sh := (*reflect.StringHeader)(unsafe.Pointer(&s))
bh := reflect.SliceHeader{Data: sh.Data, Len: sh.Len, Cap: sh.Len}
return *(*[]byte)(unsafe.Pointer(&bh))
}
注意：unsafe 不提供安全担保。一旦原 []byte 被重用或回收，对应的 string 就变成悬垂指针 —— 表现为随机乱码或 panic。只推荐用于只读、短生命周期、明确控制内存的场景（如响应体构造）。
sync.Pool + 预分配缓冲区对 io.Copy 更实际
绝大多数服务并不需要、也用不上 sendfile。比如代理层、加解密传输、内容改写等场景，数据必须经过用户态。这时优化方向很明确：减少缓冲区分配和拷贝次数。
io.Copy 默认用 32KB 缓冲区，但你可以用 io.CopyBuffer 复用 sync.Pool 中的 []byte：
- 定义全局池：
var bufPool = sync.Pool{New: func() interface{} { return make([]byte, 64*1024) }} - 调用：
buf := bufPool.Get().([]byte); n, err := io.CopyBuffer(dst, src, buf); bufPool.Put(buf) - 避免频繁 GC，尤其在高并发小文件传输中效果明显
比起折腾系统调用，这个方案跨平台、无风险、易测试，且在真实业务中往往带来更稳定的吞吐提升。
零拷贝不是银弹。Linux 上的 sendfile 只适用于文件 → socket 直传，一旦中间插入任何用户态逻辑（哪怕只是加个 header），就得回到拷贝路径。真正要压榨性能，得先确认瓶颈在哪 —— 是 CPU 在 memcpy，还是磁盘 I/O 或网络带宽卡住了。盲目上 unsafe 或 hijack，反而容易引入难以复现的内存错误。
