syscall 在 Go 中开销高是因为每次调用需用户态到内核态切换、g0栈切换、参数拷贝及信号处理准备；高频小I/O下尤为明显，而bufio缓冲和文件复用可显著优化。
为什么 syscall 在 Go 中开销比预期高
Go 的 runtime 虽然封装了系统调用，但每次调用仍需从用户态切到内核态，且涉及 g0 栈切换、参数拷贝、信号处理准备等。尤其在高频小 I/O 场景（如每秒数万次 read/write）下，这种开销会显著压垮吞吐。Go 1.14+ 引入的异步抢占和 netpoll 优化主要面向网络 I/O，对普通文件或管道读写影响有限。
用 bufio.Reader 和 bufio.Writer 批量缓冲 I/O
直接调用 os.File.Read 或 os.File.Write 几乎等价于裸 read(2)/write(2)，每次触发一次系统调用。而 bufio 通过内存缓冲将多次小操作合并为单次大系统调用，是成本最低、见效最快的优化手段。
- 对日志写入：用
bufio.NewWriterSize(f, 64*1024)替代直接f.Write，可减少 90%+ 的write调用次数 - 对逐行读取：用
scanner := bufio.NewScanner(f)，而非bytes.Buffer+f.Read循环 - 注意：
bufio.Writer必须显式调用Flush()，否则内容可能滞留在缓冲区
避免频繁打开/关闭文件 — 复用 *os.File
每次 os.Open 都触发 openat(2)，每次 Close 触发 close(2)，还伴随 fd 表查找与释放。若业务是持续写入同一日志文件或读取配置文件，应全局复用一个 *os.File 实例。
- 不要在循环里写
for _, path := range paths { f, _ := os.Open(path); ... f.Close() } - 改用
os.OpenFile(path, os.O_WRONLY|os.O_APPEND, 0644)一次打开，长期持有；关闭时机由生命周期决定 - 注意：多 goroutine 并发写同一
*os.File是安全的（内部有锁），但若需更高性能，可用sync.Pool管理bufio.Writer
绕过 Go runtime 的 syscalls：用 unix 包直连 libc
当标准库无法满足极致性能（如自研高性能日志 agent、低延迟文件监控），可跳过 os 抽象层，用 golang.org/x/sys/unix 直接调用底层 syscall。这能省去 Go runtime 的参数转换、错误码映射、goroutine 阻塞检查等额外逻辑。
立即学习“go语言免费学习笔记（深入）”；
package main
import (
"unsafe"
"golang.org/x/sys/unix"
)
func writeDirect(fd int, p []byte) (int, error) {
// 绕过 os.Write，直接 syscall
return unix.Write(fd, p)
}
func openDirect(path string) (int, error) {
return unix.Openat(unix.AT_FDCWD, path, unix.O_WRONLY|unix.O_APPEND, 0)
}
⚠️ 注意：unix.Write 不做重试（EINTR）、不自动处理 partial write，需自行判断返回值并循环；且失去 Go 的 context 取消支持，阻塞即真阻塞。
真正难的是权衡：多数服务用好 bufio 和文件复用就已消除 95% 的 I/O 瓶颈；只有极少数场景需要碰 unix 包 —— 那时你得清楚自己在放弃什么。
