syscall 成为性能瓶颈是因为每次调用都有上下文切换等固定开销，高并发小包场景下大量时间消耗在内核态而非业务逻辑。
为什么
会成为
性能瓶颈
Go 程序里看似普通的 I/O 操作（比如
、
）背后常触发系统调用，而每次陷入内核都有固定开销：寄存器保存/恢复、上下文切换、权限检查。尤其在高并发小包场景下，频繁调用
或
会让 CPU 大量时间花在内核态，而非业务逻辑。
一个典型信号是
显示每秒数万次调用，但实际吞吐却上不去——说明不是带宽瓶颈，而是系统调用本身拖慢了节奏。
用
批量读写替代裸
标准库
的
和
本质是用户态缓冲层，把多次小 I/O 合并成一次大系统调用，显著降低陷入内核频率。
对文件：避免
（它内部已用缓冲，但若需多次读取，应复用
）；改用
或
避免反复
对网络：用
替代直接
，调用
触发真实
；注意不要每写一次就
，否则失去缓冲意义
缓冲区大小要权衡：默认 4KB 通常够用；若处理日志等长行数据，可设为 64KB 减少
次数，但过大会增加内存占用和延迟
避免在 hot path 上调用
和
这些看似“纯 Go”函数其实依赖系统调用：
底层调用
，在某些内核版本或容器环境下可能变慢；
触发
并遍历 goroutine 栈，开销极大。
Python3.6标准库参考手册（PDF版）
Python3.6标准库参考手册（PDF版）
下载
立即学习
“
go语言免费学习笔记（深入）
”；
高频时间戳需求（如 metrics 打点）：用
比
快 10 倍以上，且避免重复创建
监控类调用：改用
（无系统调用）替代周期性
；真要查 goroutine 数量，用
（纯内存读取）
若必须用
，考虑在循环外缓存一次值，或使用单调时钟缓存（如
）
用
控制底层
行为
默认用 32KB 缓冲，但无法定制；而
允许你传入预分配的
，既避免反复
对大文件复制：显式传入
注意
长度不能为 0，否则退化为
行为；且需确保该切片生命周期覆盖整个
调用
配合
/
（即
+ 向量 I/O）能进一步合并系统调用，但需自己封装，适用性较窄
真正影响系统调用频次的，往往不是你写的那几行
，而是标准库中那些「看起来很安全」的包装函数——它们是否缓冲、是否复用、是否在循环里悄悄调用，得看源码才能确认。
syscallos.ReadFilenet.Conn.Writewrite(2)read(2)perf record -e syscalls:sys_enter_writebufiosyscallbufio.Readerbufio.Writeros.ReadFilebufio.Readerbufio.NewReader(f).ReadString('\n')ReadBytes('\n')read(2)bufio.NewWriter(conn)conn.Write()Flush()write(2)Flushread(2)time.Now()runtime.GoroutineProfile()time.Now()clock_gettime(CLOCK_MONOTONIC)runtime.GoroutineProfile()getrusage(2)time.Now().UnixNano()Format()time.Locationruntime.ReadMemStats()GoroutineProfileruntime.NumGoroutine()time.Now()start := time.Now(); ...; elapsed := time.Since(start)io.CopyBufferread/writeio.Copyio.CopyBuffer(dst, src, buf)[]bytemake([]byte, 32 的 GC 压力，又可匹配硬件页大小（如 64KB）提升 DMA 效率。make([]byte, 64，比默认缓冲减少约 15% 系统调用次数bufio.CopyCopyBuffersyscall.ReadvWritevio.ReadFullsyscall.Syscall