go标准库不支持sendfile/splice零拷贝，需手动调用syscall.sendfile并严格管理fd生命周期，仅linux可用，且需处理offset循环、平台约束与内核限制。
Go 里没法直接用 sendfile 或 splice
Go 标准库的 net.Conn 接口不暴露底层文件描述符，也不提供对 Linux sendfile(2) 或 splice(2) 系统调用的封装。你写 conn.Write(buf)，背后走的是用户态内存拷贝 + write(2)，不是零拷贝。
常见错误现象：以为用 io.Copy 就能触发零拷贝 —— 实际上它只是逻辑简洁，底层仍是 read(2) + write(2) 两段拷贝。
- 真正想用
sendfile，得自己调用syscall.Sendfile，且要求源文件是普通文件（os.File），目标是支持sendfile的 socket（如 TCP 连接对应的 fd） -
splice更受限：两端都得是 pipe 或支持 splicing 的 fd（比如 socket + pipe），Go 里连 pipe fd 都不轻易暴露 - 注意
syscall.Sendfile在 Windows/macOS 上不可用，跨平台代码会直接 panic 或编译失败
syscall.Sendfile 怎么安全用
必须手动获取 socket 的文件描述符，且确保它没被 Go runtime 复用或关闭。最稳妥路径是：从 net.Listener accept 后，立刻用 conn.(*net.TCPConn).File() 提取 fd，然后立即 fd.Close()（只关副本，不影响连接），再传给 syscall.Sendfile。
使用场景：HTTP 文件服务器中，响应静态文件时绕过 Go runtime 的 buffer 拷贝。
立即学习“go语言免费学习笔记（深入）”；
- 参数顺序很关键：
syscall.Sendfile(outfd, infd, offset, count)，outfd是 socket fd，infd是文件 fd，offset是文件读取起点（可为nil表示当前 offset） - 返回值是实际发送字节数，可能小于文件长度，需循环调用并更新
offset - 如果
infd是普通文件但已 mmap 过，某些内核版本下sendfile可能退化为拷贝 —— 不是 bug，是内核策略
为什么 io.Copy 看起来快，其实没零拷贝
io.Copy 默认用 32KB buffer，在用户态做 read/write 循环。即使源是 *os.File、目标是 net.Conn，Go 也不会自动降级到 sendfile —— 因为它无法保证整个过程无 GC 干扰、无 goroutine 切换、无中间 buffer 复用风险。
性能影响：小文件（10MB）在高并发下，io.Copy 的内存分配和拷贝会明显抬高 GC 压力和 CPU 占用。
- 你可以用
io.CopyBuffer传入复用的 buffer，减少 alloc，但仍是拷贝 - 标准库中只有
http.ServeFile在极少数条件下（Linux + 文件 + TCP）尝试用sendfile，但它被标记为 “best effort”，失败就 fallback 到io.Copy - 别依赖
runtime.LockOSThread强行绑定 goroutine 来“辅助”零拷贝 —— 这既不必要，还容易卡住调度器
真正要零拷贝，得接受约束和权衡
零拷贝不是开关，是妥协：你要放弃 Go 的抽象便利，直面 fd 生命周期、errno 处理、平台差异和并发安全。
容易被忽略的一点：即使 sendfile 成功，TCP Nagle 算法或延迟 ACK 仍可能让数据滞留在内核协议栈，看起来“没发出去”。这不是零拷贝的问题，但常被误认为失败。
- 若用
splice，必须自己创建 pipe（syscall.Pipe），把文件内容splice进 pipe，再splice出到 socket —— 多一步，但能绕过部分sendfile的限制（比如源不是普通文件） - 所有涉及
syscall的代码，必须加//go:build linux构建约束，否则跨平台构建直接失败 - 生产环境建议只在明确瓶颈处（如 CDN 边缘节点、大文件下载服务）用，别为了“酷”在通用 HTTP handler 里硬塞
