结论：http.ServeFile 不适合高性能流传输，因其内部强制重定向、自动 MIME 推断、忽略自定义响应头、不支持超时控制与 context 取消、无 Range 断点续传且底层仍用 io.Copy 封装过深，导致流控失控和 goroutine 泄漏。
直接说结论：用 io.Copy 配合 net.Conn 或 http.ResponseWriter 是最简、最稳的集成方式，但必须配合超时控制、缓冲区调优和错误恢复逻辑，否则高并发下容易卡死或丢数据。
为什么不能直接用 http.ServeFile 做高性能流传输
http.ServeFile 看似方便，但它内部做了强制重定向、自动 MIME 推断、文件存在性检查等额外动作，还会忽略你自定义的响应头（比如 Content-Disposition），更关键的是它不支持设置读取超时或中断恢复。在大文件下载场景中，客户端断连后服务端 goroutine 可能长期 hang 住，资源无法释放。
- 它底层仍调用
io.Copy，但封装过深，失去对流控的掌控 - 无法配合
context.Context实现请求级取消 - 不支持断点续传（
Range头），也不能动态计算ETag或校验和
io.Copy 和 io.CopyBuffer 的实际差异与选型
默认 io.Copy 使用 32KB 内部缓冲区；io.CopyBuffer 允许你显式传入一个预分配的 []byte，适合网络延迟高或磁盘 I/O 慢的场景。实测在千兆内网中，64KB 缓冲比默认提升约 12% 吞吐，在跨公网传输时提升更明显（减少系统调用次数）。
- 用
io.CopyBuffer(w, r, make([]byte, 64*1024))替代io.Copy(w, r) - 缓冲区大小不是越大越好：超过 128KB 后收益趋缓，且会增加单次内存占用
- 注意：缓冲区切片必须是局部变量或从
sync.Pool获取，避免逃逸到堆上
TCP 场景下流式文件收发的易错点
TCP 连接不像 HTTP 有明确生命周期，文件传输中途断连时，io.Copy 返回的 err 往往是 io.EOF 或 net.OpError，但此时你可能已经写了一半数据——客户端无法知道是否完整接收。
立即学习“go语言免费学习笔记（深入）”；
- 服务端发送前先写 8 字节长度头（
binary.Write(conn, binary.BigEndian, int64(fileInfo.Size()))），客户端按头读取再校验 - 每次
conn.Write后检查返回的n是否等于预期字节数，不等即出错 - 务必为
conn.SetReadDeadline和conn.SetWriteDeadline设置合理超时（如 30 秒），否则连接卡死会拖垮整个监听器 - 不要在
defer conn.Close()前做耗时操作，goroutine 可能已退出，defer不会执行
真正难的不是“怎么把文件发出去”，而是“怎么确认对方收到了、收到多少、断了之后从哪继续”。流式处理的可靠性，永远藏在超时、重试、长度头、校验和这些细节里，而不是 io.Copy 这一行代码本身。
