github.com/hpcloud/tail 是 go 中实现 tail -f 功能最稳定、生产级的第三方库，基于 inotify/kqueue 事件监听，非轮询，支持日志轮转、自动重开文件、超长行截断及跨平台，避免丢行与重复。
tail -f 的 go 等价实现用什么库
go 标准库不提供类似 tail -f 的原生支持，得靠第三方库。目前最稳定、被广泛用于生产环境的是 github.com/hpcloud/tail（注意不是 tail 单词拼写错误的 taill）。它底层基于 inotify（linux）或 kqueue（macos），能监听文件 inode 变化和追加写入，不是轮询，资源开销低。
安装：
go get github.com/hpcloud/tail
关键点：
-
tail.Tail实例会自动处理日志轮转（log rotation），只要新文件继承原文件名或符合Follow: true配置 - 默认启用
MustExist: false时，若文件尚不存在，会阻塞等待创建；设为true则直接报错 - 不建议用
os.OpenFile(..., os.O_APPEND)自己读——无法感知轮转，且容易漏掉最后一行未换行的缓冲内容
如何安全读取正在被写入的大文件（>1GB）
大日志文件本身不是问题，但读法不对会导致内存暴涨或丢数据。核心是避免一次性加载整文件，也别用 bufio.Scanner 默认的 64KB 缓冲区去扫全量——它会在找不到换行符时不断扩容，遇到超长单行（如 JSON 日志）可能 OOM。
推荐做法：
- 用
tail.Line逐行接收，每行都是独立[]byte，由库内部按需分配，不累积 - 如果必须自定义解析逻辑，用
bufio.NewReader(tail.File)+ReadString('\n')，但要加超时和长度限制 - 对超大行（比如 50MB 的 trace 日志），提前在
tail.Config中设MaxLineSize: 1024 * 1024（1MB），超出则截断并触发tail.ErrLineTooLong - 不要用
ioutil.ReadAll或bytes.Buffer拼接所有行——监控是流式行为，不是批处理
日志轮转（logrotate）下如何不丢日志
真实场景中，nginx.log 被 logrotate 切成 nginx.log.1，新日志写入空的 nginx.log——这时普通文件读取会中断。而 tail 库默认就能处理，前提是配置正确：
- 初始化时传入
tail.Config{Follow: true, MustExist: false} - 确保日志轮转使用
copytruncate或rename模式（绝大多数默认如此）；若用create新建并 chown/chmod，则旧文件句柄仍有效，新文件会被自动跟踪 - 避免在轮转后手动
os.Remove原文件——这会让内核回收 inode，导致 tail 失去跟踪能力（表现为静默停止） - 可通过监听
tail.Line.Err是否为tail.ErrRotated来确认是否发生了轮转事件（可用于触发指标重置等）
为什么用 fsnotify 不够用
有人尝试用 fsnotify 监听 WRITE 事件再自己读文件，这在多数情况下会丢数据：
- fsnotify 仅通知“有写入”，不告诉写了多少字节、从哪开始——你得自己维护 offset，极易与实际写入位置错位
- 多个进程同时写一个日志文件（如多 worker 的 Go 程序）时，
WRITE事件可能合并或丢失，尤其高频率写入 - 轮转发生时，fsnotify 会收到
RENAME或REMOVE，但无法知道新文件该从头读还是续读——而tail库通过 inotify 的IN_MOVED_TO和文件 inode 对比自动判断 - Windows 下 fsnotify 行为差异更大，而
tail库做了跨平台封装，无需额外适配
真正难的不是“怎么监听”，而是“怎么保证每行只处理一次、不重复、不遗漏”，这个边界 case 在高吞吐日志场景下极容易暴露。轮转+并发写+超长行+程序重启，四者叠加时，手写逻辑几乎必然出错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
