Go语言通过Goroutine并发模型高效处理I/O密集型任务，核心优化包括：避免轮询、合理使用bufio缓冲减少系统调用、复用连接与对象以降低GC压力。
Go 语言本身不提供传统意义上的“异步 I/O”（如 Linux 的 io_uring 或 Windows 的 IOCP），它的 net/http、os.File 等底层 I/O 操作默认是同步阻塞的，但通过 Goroutine + Channel 的并发模型和合理的缓冲策略，可以高效应对 I/O 密集型场景。真正的优化重点在于：避免阻塞等待、减少系统调用次数、控制内存分配、利用内核缓冲与 Go 运行时调度协同。
用 Goroutine 并发替代“伪异步”轮询
不要试图用 select + time.After 模拟非阻塞 I/O；Go 的哲学是“不要通过共享内存来通信，而要通过通信来共享内存”。对多个 I/O 操作（如读多个文件、调用多个 API），直接启动独立 Goroutine，并用 WaitGroup 或 errgroup 管理生命周期。
- ✅ 正确做法：每个 HTTP 请求或文件读取放在单独 Goroutine 中，由 Go 调度器自动挂起/唤醒
- ❌ 错误做法：用 for+select+time.After 做忙等轮询，既浪费 CPU 又无法真正释放线程
- 示例：用 errgroup.Group 同时发起 10 个 HTTP 请求，失败时自动取消其余请求
合理使用 bufio 缓冲，减少系统调用频次
每次 Read() / Write() 都可能触发一次系统调用，开销不小。bufio.Reader/Writer 在用户态维护缓冲区，把多次小读写合并为一次大 I/O，显著降低 syscall 次数。
- 读大文件时，用 bufio.NewReaderSize(f, 64*1024) 设置 64KB 缓冲（默认 4KB，常不够）
- 写日志或响应体时，用 bufio.NewWriterSize(w, 32*1024)，并在最后调用 Flush()
- 注意：bufio 不改变底层阻塞行为，但它让“阻塞”的单位变大、次数变少，整体吞吐更高
复用连接与对象，避免高频分配
I/O 密集型程序常因频繁创建连接、buffer、encoder 而触发 GC 压力，间接拖慢 I/O 处理速度。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 客户端启用连接复用：http.DefaultTransport.MaxIdleConns = 100，MaxIdleConnsPerHost = 100
- 解析 JSON 时复用 json.Decoder（它内部自带缓冲），避免反复 new bytes.Buffer
- 读文件循环中，复用同一块 []byte 切片（如 make([]byte, 1io.ReadFull 或 ReadAtLeast
必要时切换到更底层的 I/O 控制方式
标准库满足大多数场景，但在极端高吞吐（如代理网关、实时日志采集）下，可考虑：
- 使用 syscall.Read/Write 绕过 Go 标准库缓冲（需自行管理 buffer 和 EAGAIN）
- 搭配 epoll/kqueue 的封装库（如 golang.org/x/sys/unix），但会失去跨平台性
- 评估是否真需要——多数瓶颈不在内核 I/O 层，而在业务逻辑、序列化、锁竞争或 GC
基本上就这些。Go 的 I/O 优化不是追求“单次调用更快”，而是让“大量并发 I/O 更稳、更省、更可控”。关键是理解 Goroutine 的阻塞本质、善用缓冲层级、减少无谓分配。不复杂但容易忽略。
