syscall调用一多就变慢，因其每次需用户态到内核态切换，开销达数百纳秒至微秒级，并打断CPU流水线、清空TLB和缓存；高频小数据syscall（如逐字节Write）90%耗时在切换而非实际操作。
为什么 syscall 调用一多就变慢？
因为每次 syscall 都要从用户态切换到内核态，这个上下文切换开销固定在几百纳秒到微秒级；更关键的是，它会打断 CPU 流水线、清空 TLB 和部分缓存。如果你在循环里反复调用 syscall.Write 写 1 字节，实际耗时可能 90% 都花在切换上，而不是写数据本身。
常见触发场景包括：os.Open + os.Read 小块读、time.Now() 在高频 tick 中滥用、用 os.Stat 检查文件是否存在而非缓存状态、或直接调用 syscall.Syscall 封装低层接口却没批处理。
用 bufio 缓冲替代高频 read/write 系统调用
标准库的 os.File 本身不带缓冲，每次 Read 或 Write 都是一次系统调用。换成 bufio.Reader 或 bufio.Writer 后，底层自动聚合多次操作为一次大块 read/write。
-
bufio.NewReaderSize(f, 64*1024)比默认 4KB 缓冲更适合大文件顺序读 bufio.NewWriterSize(f, 1 写日志时设 64KB 缓冲，再配合w.Flush()控制刷盘时机- 注意：
bufio.Scanner默认 64KB 缓冲，但遇到超长行会自动扩容——可能引发意外内存分配，可设sc.ScanBytes()或用bufio.Reader.ReadBytes更可控
避免在热路径中调用 time.Now() 和 os.Getpid()
这两个看似轻量的函数背后都是系统调用：time.Now() 调 clock_gettime(CLOCK_MONOTONIC)，os.Getpid() 调 getpid()。在每毫秒执行数百次的 goroutine 里调用，会快速成为瓶颈。
立即学习“go语言免费学习笔记（深入）”；
- 时间戳需求：启动时缓存
start := time.Now()，后续用time.Since(start)（纯 Go 实现，无系统调用） - 需要高精度单调时钟：直接用
runtime.nanotime()（返回纳秒数，无系统调用，但需自己转成time.Time时谨慎） - PID 需求：启动时调一次
os.Getpid()存全局变量，别在循环里重复取
批量系统调用与 unix 包的合理使用
Go 标准库对某些场景做了封装隐藏，比如 os.ReadDir 底层是单次 getdents64 调用，比旧版 Readdir（多次 readdir）高效得多；但有些需求仍需直面系统调用——这时优先用 golang.org/x/sys/unix 而非裸 syscall。
-
unix.Readv/unix.Writev支持 scatter-gather I/O，一次调用处理多个 buffer，比循环调Read快 2–5 倍 -
unix.Mmap替代频繁os.Read大文件，尤其适合只读随机访问场景 - 慎用
unix.Syscall：它不处理EINTR重试，而unix.Read等封装函数会自动重试，直接裸调容易漏错误分支
真正卡点往往不在“能不能调”，而在“调多少次”和“调什么时机”。比如一个 HTTP handler 里每请求做 3 次 os.Stat，换成启动时预加载配置文件的 os.FileInfo 并复用，性能差异可能比换 Web 框架还明显。
