最常被低估的性能瓶颈是频繁系统调用；应使用 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 后批量读页）确实是冗余。但绕过意味着你亲手接管风险。
