os.Read 比 bufio.Reader.Read 慢因每次调用均触发系统调用，而后者用4KB缓冲区减少syscall频次；建议顺序读取时统一用bufio.NewReader，小粒度读取收益更明显。
为什么 os.Read 比 bufio.Reader.Read 慢很多？
直接调用 os.Read 会绕过缓冲，每次读都触发系统调用，频繁小读（比如逐字节）时开销极大。而 bufio.Reader 在用户态维护一块默认 4KB 的缓冲区，一次系统调用读多字节，后续从内存取，大幅降低 syscall 频次。
实操建议：
- 对文件或网络连接做顺序读取时，一律包装成
bufio.NewReader，尤其当读取粒度小于 1KB 时收益明显 - 若已知数据块大小较固定（如日志行平均 200B），可显式指定缓冲区大小：
bufio.NewReaderSize(conn, 8192) - 注意：
bufio.Reader的Read方法不保证填满传入的[]byte，需检查返回的n值，不能假设 len(buf) == n
使用 io.Copy 替代手动循环读写是否真能提升性能？
是的，而且提升显著。io.Copy 内部使用 32KB 缓冲区，并针对不同场景做了优化：对支持 ReadFrom/WriteTo 的类型（如 *os.File 到 *os.File）会直接走零拷贝系统调用（sendfile 或 copy_file_range）；否则退化为带缓冲的循环。
常见误用：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 自己写
for { n, _ := src.Read(buf); dst.Write(buf[:n]) }—— 不仅逻辑冗余，还容易忽略错误传播和边界判断 - 在 HTTP handler 中用
io.Copy(w, file)但没设Content-Length或启用Transfer-Encoding: chunked，导致客户端无法判断响应结束 - 对小文件（io.Copy 反而增加函数调用和缓冲分配开销，此时直接
ioutil.ReadFile（Go 1.16+ 改为os.ReadFile）更合适
网络 I/O 中，net.Conn.SetReadBuffer 和 SetWriteBuffer 有用吗？
有用，但效果高度依赖操作系统和实际负载。这两个方法设置的是内核 socket 缓冲区大小，影响 TCP 接收/发送队列容量，不直接影响 Go 层的 Read/Write 行为。
关键事实：
- Linux 默认接收缓冲区约 212992 字节（208KB），写缓冲区约 212992 字节；调用
SetReadBuffer(1024*1024)可能成功，但内核可能按页对齐后截断（如只接受 1MB 对齐值） - 仅在高吞吐、低延迟敏感场景（如实时流服务）才值得调整；普通 API 服务几乎无感
- 必须在
conn建立后、首次读写前调用，否则返回EINVAL错误 - 配合
net.Conn.SetNoDelay(false)（即开启 Nagle 算法）时，增大写缓冲可能加剧小包合并延迟，需权衡
内存映射文件（syscall.Mmap）适合什么场景？
syscall.Mmap 把文件直接映射进进程虚拟内存，避免内核态与用户态间的数据拷贝，适合大文件随机读、只读分析类任务（如日志索引、图像元数据提取）。但它不是万能加速器。
注意事项：
- Go 标准库不封装
Mmap，需用golang.org/x/sys/unix或第三方库（如memmap）；Windows 需用syscall.CreateFileMapping - 映射后访问越界会触发
SIGBUS，Go 运行时无法 recover，程序直接崩溃 - 文件被外部修改时，映射内容可能不一致；若需强一致性，应配合
flock或应用层锁 - 映射本身不加载数据到物理内存，首次访问页时才触发缺页中断（lazy loading），这点和预读（
readahead）策略不同
