net.conn默认不支持零拷贝，因go安全模型禁止直接暴露内核页帧，read/write必须经用户空间缓冲；真正零拷贝需绕过conn、用syscall.sendfile或io.readerfrom（如os.file）配合net.tcpconn触发。
为什么 net.Conn 默认不支持零拷贝
Go 的 net.Conn 接口抽象了底层 socket，但它的 Read() 和 Write() 方法必须把数据搬进用户空间缓冲区——这是语言安全模型决定的：Go 不允许直接暴露内核页帧给用户态代码。所以像 sendfile()、splice() 这类真正零拷贝系统调用，无法通过标准 Conn 接口触发。
常见误区是以为加个 bufio 就算“优化”，其实它只是合并系统调用，并未减少数据拷贝次数；反而因额外内存分配加重 GC 压力。
- 真正零拷贝只在特定路径成立：文件 → kernel page cache → socket buffer → NIC，全程不经过用户空间
- Go 标准库中唯一能触发
sendfile的地方是http.ServeFile（内部调用syscall.Sendfile） - 自定义 TCP 网关若想走零拷贝，必须绕过
Conn.Write()，改用syscall.Sendfile或io.Copy配合支持ReaderFrom接口的底层对象（如*os.File）
如何让 TCP 转发走 sendfile 路径
网关做中继转发时，若后端返回的是本地文件（比如静态资源、预生成响应体），可跳过用户态内存中转，直接由内核完成传输。关键在于：后端连接需是 *net.TCPConn，且响应体来源必须是实现了 io.ReaderFrom 的类型（如 *os.File）。
示例逻辑：
// 假设 respBody 是 *os.File 类型
if rf, ok := respBody.(io.ReaderFrom); ok {
n, err := rf.ReadFrom(srcConn)
// 此处实际触发 sendfile 系统调用
}
- 必须确保 srcConn 是
*net.TCPConn，否则ReadFrom会 fallback 到普通 copy - Linux 内核要求源 fd 支持
splice（如普通文件、socket），目标 fd 必须是 socket - 不能对加密/压缩/修改后的响应体使用该方式——任何用户态处理都会破坏零拷贝链路
netpoll 与零拷贝能否共存
可以，但要分清职责：netpoll 负责高效等待 I/O 就绪（epoll/kqueue），而零拷贝负责减少数据搬运。两者不冲突，反而是互补关系：netpoll 让你用更少 goroutine 等待海量连接，零拷贝让你在单次转发中省掉 2 次内存拷贝。
实操中容易踩的坑：
- 在
netpoll触发可读事件后，仍用conn.Read()读取 header —— 这部分无法零拷贝，但必须做，因为要解析协议 - header 解析完，若确认后续是纯文件转发，应立刻切换到
io.Copy+os.File+TCPConn.ReadFrom路径 - 不要试图对整个连接启用零拷贝：TCP 流无边界，而
sendfile只能按文件 offset+length 发送固定块
什么时候该放弃零拷贝
零拷贝不是银弹。当你的网关需要做以下任意操作时，强制走零拷贝反而降低性能或引入 bug：
- 修改响应头（如添加
X-Forwarded-For）—— 必须先读入内存解析并重写 - 流式 gzip 压缩 —— 所有压缩逻辑都在用户态，必然经过内存
- 协议转换（如 TCP → HTTP/2 Frame）—— 帧封装无法绕过用户空间
- 限流/审计日志需采样 body —— 必须完整读取内容
真实高性能网关往往是混合模式：header 解析和控制逻辑走常规路径，大块静态响应体走 sendfile，中间状态用 sync.Pool 复用 bufio.Reader/Writer 缓冲区——把零拷贝留给真正适合它的场景，而不是强求全覆盖。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
