tail实现的核心难点是文件重写和轮转时的偏移丢失，需同时监控文件大小变化、inode变更与truncate事件，通过os.Stat比对并重置reader，手动分块读取+缓存未完成行，避免Scanner丢行，轮询Stat比fsnotify更稳可靠。
tail 实现的核心难点是文件重写和轮转时的偏移丢失
go 标准库没有内置 tail，直接用 os.Seek + os.Read 读取末尾容易在日志轮转（logrotate）或 truncate 后失效——因为文件 inode 可能不变但内容已清空，而你的 offset 还停在旧位置，导致跳过新内容甚至反复读旧残片。
真正健壮的 tail 必须同时监控：文件大小变化、inode 是否变更、是否被 truncate。不是简单“从 EOF 往前找换行符”就够的。
- 用
os.Stat()检查fi.Size()和fi.Sys().(*syscall.Stat_t).Ino（linux/macos），每次循环都比对 - 发现 size 缩小或 inode 不一致，就重置 reader：关闭旧
*os.File，os.Open新句柄，从头开始 scan（或按需跳到新末尾） - 避免用
time.Sleep轮询太密——100ms 是较稳妥下限；太短浪费 CPU，太长延迟高
用 bufio.Scanner 配合 Seek 读取最新行时的边界问题
bufio.Scanner 默认按行读，但 tail 场景需要“从某偏移开始往后读所有完整行”，不能依赖 Scan() 自动跳过不完整行——否则会漏掉最后一行（还没换行符的正在写入的日志）。
更可控的做法是：用 os.Read 或 io.ReadAtLeast 手动读块，自己切分行，保留未完成行缓存。
立即学习“go语言免费学习笔记（深入）”；
- 初始化时先
file.Seek(0, io.SeekEnd)，再倒着找最近的n（最多回溯 4KB，防大行卡死） - 后续增量读取用
file.Read(buf)，把 buf 内容按n分割，未闭合的行存进pendingLine字符串 - 每次输出前拼上
pendingLine + newLine，再清空pendingLine - 别用
Scanner.Split(bufio.ScanLines)——它内部会丢弃不完整行，tail 场景下这是致命行为
监听文件变化该选 fsnotify 还是轮询
用 fsnotify 看起来高级，但实际在 tail 场景下反而更难处理：它只报事件（WRITE、CHMOD），不告诉你写了多少字节，也不保证事件顺序；而日志轮转常伴随 RENAME + CREATE，你得自己关联新旧文件。
对大多数日志文件（尤其是本地磁盘），简单轮询 Stat() 更稳、更易调试。fsnotify 适合监听配置目录或临时触发场景，不是 tail 的刚需。
- 轮询开销极低：单文件每 100ms 一次
os.Stat，系统调用成本可忽略 - 若真要用
fsnotify，必须监听原路径的FSNotify实例，并在收到Remove或Chmod（权限突变）时主动Stat验证是否轮转 - 注意
fsnotify在容器内可能不可用（/proc/sys/fs/inotify/max_user_watches 被限），而轮询无此限制
支持 -n 和实时追加时的内存与性能取舍
tail -n 20 要从末尾往前翻 20 行，但日志行长不定——一行可能几 KB（堆栈），也可能几个字节。硬算行数容易 OOM 或卡死。
安全做法是限定最大回溯字节数（比如 1MB），在这个范围内尽可能多取行，不够 20 行就全给，不强求。
- 用
bytes.LastIndex在 buffer 中倒找n，每次找到就计数 +1，超 20 行或超 1MB 就停 - 实时追加阶段不要把历史行全塞进内存再打印——边读边
fmt.Fprintln(os.Stdout, line) - 如果要支持管道输出（如
tail -f access.log | grep "404"），确保 stdout 是行缓冲的：os.Stdout.Sync()或用bufio.NewWriter(os.Stdout)并及时Flush()
最麻烦的永远不是“怎么读到新行”，而是“怎么确认这行真是新的、没重复、没遗漏”。inode 检查、truncate 检测、未完成行缓存，三者缺一不可。少一个，上线跑两天就出问题。