Go中mmap无标准库原生支持，须用syscall.Mmap或封装库如mmap-go；映射后必须显式Flush才能持久化，且需校验文件大小、权限及平台差异。
Go 语言里没有“调个函数就零拷贝”的路径，文件读写想真正绕过用户态内存拷贝，必须满足内核能力、fd 类型、连接状态三重严苛条件；绝大多数 io.Copy 或 http.ServeFile 都在做两次 CPU 参与的搬运，CPU 飙高、吞吐卡在 100MB/s 以下就是典型信号。
file.WriteTo(conn) 什么时候真走 sendfile？
这是标准库中唯一可能触发零拷贝的“安全出口”，但它不是 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。哪怕你传入一个普通文件，也绕不开用户缓冲区中转：
立即学习“go语言免费学习笔记（深入）”；
-
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.Mmap 读写大文件的坑在哪？
syscall.Mmap 不是传输层零拷贝，只是省掉用户态 memcpy；它仍走 page cache，收益集中在大文件随机读、多进程共享访问或配合 madvice 做预读：
- 映射长度不能超过文件实际大小（
os.Stat先查），否则Mmap返回EINVAL - 映射后得到的
[]byte切片禁止append或重切（会 panic），底层是虚拟内存地址 -
mmap写文件时，msync不是可选项而是强依赖：用MAP_SHARED映射后修改内存，内核只保证“最终”刷盘，断电或崩溃可能丢数据 - Go runtime GC 不管理 mmap 内存，必须显式
syscall.Munmap，否则泄漏（runtime.ReadMemStats里的HeapSys不含它，但VmSize会涨）
小文件（mmap 反而更慢：page fault 和 TLB 压力盖过了复制成本；并发读多个 mmap 区域时，若没控制总映射大小，容易触发 ENOMEM（进程虚拟内存耗尽）。
替代方案比硬啃 syscall 更实用
除非你明确需要多进程共享内存或精细控制 page fault 行为，否则优先考虑更稳的路径：
- 纯读大文件：用
bufio.NewReader(os.NewFile())+ReadAt，结合os.File.Seek随机读；现代 Linux 的 read-ahead 已很高效 - 需要零拷贝网络：上
golang.org/x/net/http2/h2c或fasthttp（其Ctx.SendFile显式调用sendfile） - 本地文件复制：Go 1.19+ 的
os.CopyFile在 Linux 上会自动尝试copy_file_range，无需手写 syscall - 缓冲区复用：用
sync.Pool复用[]byte缓冲（如var bufPool = sync.Pool{New: func() interface{} { return make([]byte, 64*1024) }}），比纠结sendfile是否生效更立竿见影
跨平台兼容性必须前置考虑：Windows 没有 sendfile，macOS 的 sendfile 不支持 socket → socket；别硬写条件编译去调用 syscall，Go 官方明确不鼓励直接 syscall 驱动网络传输——容易出错且难维护。
