syscall 是性能瓶颈，因其涉及用户态/内核态切换、寄存器保存/恢复及权限检查等开销，高并发下显著拖慢吞吐；容器或云环境中该开销更明显。
为什么 syscall 是性能瓶颈？
Go 程序中每次调用 os.Open、os.Write、net.Conn.Read 等，底层都可能触发一次或多次系统调用。而系统调用涉及用户态/内核态切换、寄存器保存/恢复、权限检查等开销，在高并发或高频 IO 场景下会明显拖慢吞吐量。尤其在容器环境或云主机上，这种开销被放大得更明显。
用 bufio.Reader 和 bufio.Writer 批量读写文件或网络流
直接对 *os.File 或 net.Conn 调用 Read/Write，容易导致「一次系统调用只处理几个字节」。bufio 通过内部缓冲区把多次小操作合并成一次系统调用，显著降低调用频次。
- 对文件：避免逐行
f.Read([]byte{...})，改用bufio.NewReader(f)+ReadString('\n')或ReadBytes('\n') - 对网络连接：用
bufio.NewWriter(conn)替代直接conn.Write()；注意写完后必须显式调用w.Flush()，否则数据可能滞留在缓冲区 - 缓冲区大小默认是 4096 字节，若已知数据块较大（如日志行平均 2KB），可手动指定更大尺寸：
bufio.NewReaderSize(f, 8192)
复用 net.Conn 和 http.Client，避免频繁建连
每次 net.Dial 或 http.Get 都包含 TCP 握手（SYN/SYN-ACK/ACK）、TLS 握手（如果启用 HTTPS）等多次系统调用。连接复用能跳过这些步骤。
-
http.Client默认启用了连接池（Transport.MaxIdleConns和MaxIdleConnsPerHost控制），但若手动设置了Transport并禁用了IdleConnTimeout或设为 0，连接不会被复用 - 不要每次请求都新建
http.Client，全局复用一个实例；如需定制超时，优先改用context.WithTimeout传入Do - 长连接场景（如 WebSocket、gRPC 流）务必使用
KeepAlive选项，并确保服务端也开启对应配置，否则连接可能被中间设备（如 NAT、LB）静默断开
用 unsafe.Slice + syscall.Read/Write 绕过 Go runtime 的封装（慎用）
标准库的 os.File.Read 内部仍会做切片合法性检查、错误包装、偏移维护等。在极致性能要求且数据可信的场景（如 mmap 后的内存页读取），可绕过 os.File，直接调用底层 syscall.Read 并配合 unsafe.Slice 构造底层数组视图。
立即学习“go语言免费学习笔记（深入）”；
fd := int(file.Fd()) buf := unsafe.Slice((*byte)(unsafe.Pointer(&data[0])), len(data)) n, err := syscall.Read(fd, buf)
- 仅适用于已知 fd 有效、且 buf 指向的内存生命周期可控的场景（如预分配大 buffer 池）
- 失去 Go 运行时的边界检查和 GC 可见性，一旦
buf指向被回收的内存，会引发难以调试的 panic 或数据错乱 - Windows 下需用
syscall.ReadFile替代，且参数结构不同；跨平台代码应避免此做法
真正影响系统调用次数的，往往不是单次调用耗时，而是调用频次与上下文切换的累积效应。缓冲、复用、预分配这三类手段里，最容易忽略的是「缓冲区大小与实际负载不匹配」——比如用默认 4KB 缓冲读取平均 128B 的消息，仍会每 32 次读就触发一次系统调用，优化效果大打折扣。
