go 不支持对普通文件使用 epoll/kqueue 等多路复用机制，因其内核不支持注册常规文件描述符，调用 epoll_ctl 会返回 einval；go runtime 也未将 os.file i/o 纳入 netpoll 调度，所有读写均走阻塞系统调用，goroutine 被挂起而非事件驱动唤醒。
Go 语言本身不提供类似 epoll/kqueue 的用户态 IO 多路复用接口，os.File 是阻塞式文件描述符，无法被 select 或 runtime.netpoll 直接管理——所以“用 IO 多路复用优化大批量文件读写”这个思路在 Go 里不成立，硬套会踩坑。
为什么 Go 里不能对普通文件做 IO 多路复用
Linux 的 epoll、FreeBSD 的 kqueue 等机制只支持 socket、pipe、eventfd 等可异步通知的 fd 类型，而常规磁盘文件（S_IFREG）的 fd 不支持 EPOLLIN/EPOLLOUT 事件注册。调用 epoll_ctl 添加普通文件 fd 会直接返回 EINVAL 错误。
Go 的运行时调度器也未将普通文件 I/O 纳入网络轮询器（netpoll）路径，所有 os.Read/os.Write 调用最终都走系统调用阻塞，goroutine 会被挂起，但这是由 OS 内核完成的等待，不是 Go runtime 的事件驱动。
-
os.Open返回的*os.File不可被select检测就绪状态 -
bufio.Reader、io.Copy等封装仍基于阻塞 read/write，只是加了缓冲或批处理 - 试图用
syscall.EpollCreate1+syscall.EpollCtl注册普通文件 fd 会失败
真正有效的批量文件 I/O 优化手段
既然多路复用走不通，实际应转向 Go 原生支持且经验证的模式：流式缓冲 + 并发节制 + 内存复用。
- 读大文件：用
os.Open+bufio.NewReaderSize(f, 1（1MB 缓冲），配合 <code>Read()或Scanner，避免os.ReadFile - 写大文件：用
os.Create+bufio.NewWriterSize(f, 1，写完必须 <code>w.Flush()，否则数据滞留在内存 - 多文件并发：用带缓冲的 channel 或
sem := make(chan struct{}, 20)控制 goroutine 数量，防止too many open files - 避免内存泄漏：不用
scanner.Bytes()直接存 slice，改用scanner.Text()或显式拷贝append([]byte(nil), b...)
什么情况下能用到“类多路复用”的替代方案
仅当文件 I/O 和网络 I/O 混合时，可通过 channel 统一调度，形成逻辑上的“多路”协调，但这不是内核级多路复用，而是 Go 的并发模型抽象：
- 一个 goroutine 持续从多个文件中读取块，发送到
chan []byte - 另一组 goroutine 从该 channel 消费数据、处理、再发往
chan []byte写入目标文件 - 用
sync.WaitGroup+close(ch)控制流程终止，防止 writer 卡死 - 这种流水线本质是解耦读/算/写阶段，靠 channel 背压实现节奏控制，不是 fd 就绪通知
真正容易被忽略的点是：别在机械硬盘上盲目开 100 个 goroutine 读不同文件——寻道延迟会让吞吐暴跌；SSD 上也建议并发数 ≤ 32，且每个 goroutine 应独占 *os.File，不要共享句柄。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
