Go语言如何低开销阻塞式实时读取正在写入的文件

你要实现的是类tail -f的日志尾随逻辑，核心要避开所有轮询类方案，用操作系统原生的文件事件通知机制实现阻塞等待，才能同时满足低延迟、低开销的要求：

• 不管是EOF后直接空转循环、定时time.Sleep()重试、反复调用Buffered()检查缓存长度，本质都是轮询：空转会占满CPU，Sleep会引入额外的读取延迟，反复检查缓存也会产生无意义的系统调用开销，都不是符合Go设计习惯的实现。
• 正确逻辑的底层依赖是操作系统内核提供的文件系统事件通知能力：当监控的文件有新内容写入时，内核会主动推送事件，监听事件的协程在事件到来前会完全处于阻塞挂起状态，完全不占用CPU时间，事件触发后立刻执行读取，延迟可以做到微秒级，没有多余开销。

具体实现的关键规则 #

1. 打开目标文件后先正常读取，直到读到当前文件的EOF位置，记录当前的文件读取偏移量，不要立刻重试读取。
2. 给打开的文件注册写入事件监听，之后阻塞等待事件到来：这个等待过程是操作系统层面实现的阻塞，不会有Go调度层面或者CPU空转的开销。
3. 当收到文件写入事件后，从上次记录的偏移位置继续往后读取内容，一直读到本次写入后的新EOF位置，把读到的完整行按你的业务逻辑处理，更新读取偏移量后再次回到事件等待状态。注意不要读一行就回去等事件，单次写入可能包含多行内容，要一次性读完当前所有新内容避免漏读。
4. 额外处理日志场景的常见边界：如果收到文件截断事件（比如日志轮转时文件被清空），就把读取偏移重置到文件开头；如果监控的文件被删除/重命名，就阻塞等待同名新文件创建后，重新打开新文件继续跟踪即可。

协程改造本身没有特殊要求：整个「监听事件-读取内容」的逻辑本身就是阻塞式的，直接放到独立goroutine中运行，通过channel把读到的日志行向外传递给其他协程处理，就是最符合Go语言「通过通信共享内存」设计习惯的写法，完全不需要额外的调度优化。

官方相关的实现参考 #

如果要从零实现，不需要依赖第三方库，可以直接使用Go官方维护的系统调用扩展包封装的原生接口：

• Linux 平台对应inotify系列系统调用
• macOS/BSD 平台对应kqueue系列系统调用
• Windows 平台对应ReadDirectoryChangesW系统调用
  这些接口的事件等待方法本身就是阻塞设计，调用后会一直挂起直到对应文件事件到来，不会产生轮询开销。你原本写的按行读取的bufio.Reader逻辑完全可以复用，只需要把原来EOF后直接continue的轮询部分，替换成阻塞等待写入事件的逻辑即可。

不要使用短Sleep降频的折中方案：哪怕把Sleep间隔设到10ms，最坏情况下就会有10ms的读取延迟，在文件长时间没有写入的场景下，依然会产生每秒上百次无意义的唤醒和系统调用，效率远低于事件通知方案。

内容的提问来源于stack exchange，提问作者Grismar