tail包是go中实现文件尾部实时追踪最直接成熟的选择，因其内置处理日志轮转、截断、重命名等真实场景；标准库os.open+bufio.scanner遇eof即退出，无法等待新内容，手动轮询易漏行、卡半行、偏移失效，且无法感知文件替换。
tail 包是 Go 中实现文件尾部实时追踪最直接、最成熟的选择，不是自己手撸轮询或 fsnotify 监听就能稳住的——尤其面对日志轮转、截断、重命名这些真实场景。
为什么不能用标准库 os.Open + bufio.Scanner 简单循环读？
因为一遇到 io.EOF 就退出，不会等新内容；手动加 time.Sleep 轮询又容易漏行、丢偏移、卡在半行、无法感知文件被替换。更麻烦的是：logrotate 一跑，原文件 inode 可能还在，但内容已清空，你的 Seek 偏移就彻底失效，后续所有读都是旧残片或跳过新日志。
tail.TailFile 的核心配置项怎么选？
关键不在“怎么启动”，而在“怎么不死、怎么不丢”：
-
Follow: true—— 必开，否则读完就停，不是tail -f是cat -
ReOpen: true—— 日志轮转必备，检测到文件被重命名/截断/删除后自动重新打开（注意：它依赖os.Stat对比 inode 和 size，不是靠事件） -
Poll: true—— 在 NFS、容器挂载卷、某些 Windows 文件系统上必须开；inotify（默认）在这些环境可能静默失效或权限不足 -
MustExist: false—— 允许监控尚未创建的文件（比如服务启动前日志还没生成），tail会阻塞等待，而不是报错退出 -
Location: &tail.SeekInfo{Offset: 0, Whence: io.SeekEnd}—— 从末尾开始，这是默认行为，显式写上更可控；若需从头读（如首次接入历史日志），改Offset: 0, Whence: io.SeekStart
常见崩溃点和对应处理
你写的 for line := range t.Lines 看似简单，但实际运行中会突然卡死或退出：
- 通道关闭后没检查
t.Err()——t.Lines关闭不等于成功结束，可能是文件被rm且ReOpen: false，此时t.Err()返回非 nil 错误，必须捕获并决策是否重启 - 没调
defer t.Cleanup()——tail内部持有文件句柄和 goroutine，不清理会导致资源泄漏，尤其在短命命令行工具里极易复现 - 忽略
line.Err字段 —— 某些行解析失败（比如 UTF-8 截断、超长行），line.Text是空，但line.Err非 nil，直接fmt.Println(line.Text)会丢异常信息 - 并发读同一文件时没加锁 ——
tail实例不是 goroutine-safe 的，多个地方共用一个t实例去读t.Lines会 panic
要不要用 fsnotify 替代 Poll: true？
不要。除非你在监听配置目录变化，而不是日志内容流。
fsnotify 只告诉你“文件被写了”，不告诉你写了多少字节、也没法帮你定位新内容起始位置；而日志轮转常伴随 rename + create，你得自己做 inode 映射和 offset 重置——这正是 hpcloud/tail 内部已做好的事。轮询 os.Stat 每 100ms 一次，开销几乎为零，稳定性却高得多。真要优化，优先调低 Poll 间隔（比如 50ms），而不是换通知机制。
真正容易被忽略的，是 ReOpen 触发后的状态一致性：它会新建文件句柄，但不会自动把旧缓冲区里未完成的行吐出来。如果你的应用对“行完整性”敏感（比如 JSON 日志、带时间戳的结构化输出），得自己缓存 pending 行并在 ReOpen 后拼接——tail 不负责这个。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
