最常被低估的性能瓶颈是频繁系统调用；应使用 bufio 缓冲 I/O、复用 http.Client 与连接池、复用 json.Decoder，并谨慎评估 unsafe 优化。
Go 程序里最常被低估的性能瓶颈，不是 GC，也不是 goroutine 调度，而是频繁的系统调用（syscall）。每次 os.Read、net.Conn.Write、甚至 os.Open 都可能触发一次或多次内核态切换——这在高并发或云环境里，开销会被显著放大。
用 bufio.Reader 和 bufio.Writer 合并小读写
直接对 *os.File 或 net.Conn 调用 Read/Write，很容易变成「读 12 字节就 syscall 一次」。而 bufio 在用户态维护缓冲区，把几十次小操作压成一次大 I/O。
- 读文件时：别用
f.Read(buf)循环，改用bufio.NewReader(f)+ReadString('\n')或Scanner（后者更轻量，适合按行） - 写日志或 HTTP 响应：用
bufio.NewWriterSize(w, 32*1024)，写完必须显式Flush()，否则数据卡在内存里不落盘 - 默认缓冲是 4096 字节，但若你处理的是平均 5KB 的日志行，建议设为
64 * 1024；过大浪费内存，过小仍频繁填缓冲
复用连接和对象，跳过重复握手与分配
每次 http.Get 或 net.Dial 都包含 TCP 握手、TLS 协商等多轮 syscall。连接池不是自动生效的魔法——它需要你没关掉它。
-
http.Client必须全局复用，不要每次请求 new 一个；如需超时控制，用context.WithTimeout传给Do，而非新建 Client - 检查你的
http.Transport：确保MaxIdleConns和MaxIdleConnsPerHost设为合理值（如 100），且IdleConnTimeout没被设为 0 或负数 - 高频解析 JSON？复用
json.Decoder，它内部自带缓冲；别每次json.Unmarshal都 new 一个bytes.Buffer
慎用 unsafe.Slice + syscall.Read 绕过 runtime
标准库的 os.File.Read 会做边界检查、错误包装、偏移管理——这些在极致吞吐场景（如 mmap 后批量读页）确实是冗余。但绕过意味着你亲手接管风险。
立即学习“go语言免费学习笔记（深入）”；
- 只适用于 fd 稳定、buf 生命周期可控的场景，比如从
sync.Pool拿的预分配大 buffer - 代码形如：
fd := int(file.Fd()); buf := unsafe.Slice((*byte)(unsafe.Pointer(&data[0])), len(data)); n, err := syscall.Read(fd, buf) - 一旦
buf指向的内存被 GC 回收，就会 panic 或静默错乱——没有运行时保护，调试成本极高 - 跨平台性也丢掉了：Windows 下得换
syscall.ReadFile，无法编译通过
真正难的不是知道该用 bufio，而是判断缓冲区该设多大、连接池参数该调到哪、以及什么时候该停手——因为再往下，就不再是 Go 层优化，而是要和内核调度、磁盘队列、网络中间件博弈了。
