os.seek不能直接用于实时索引更新，因为其仅能定位当前文件字节位置，无法感知外部追加导致的长度变化，易引发io.eof、重复消费或漏读；须配合os.stat()轮询size()变化，并注意nfs缓存、inotify边界及truncate风险。
为什么 os.Seek 不能直接用于实时索引更新
因为文件可能被外部进程追加写入，而 os.Seek 只能定位到当前已存在的字节位置；一旦文件增长，旧的偏移量就失效，且 Go 的 os.File 不会自动感知文件长度变化。你得自己轮询或监听变更，否则索引会卡在旧末尾。
常见错误现象：io.EOF 突然出现、索引重复消费最后几行、新内容完全不触发回调。
- 用
os.Stat()检查Size()是否增长，比单纯Seek更可靠 - 不要在循环里无休止
Seek+Read，先确认长度变了再读新增部分 - 注意文件系统缓存（如 NFS），
Stat()可能延迟，需搭配小间隔重试
如何用 bufio.Scanner 安全读取增量内容
bufio.Scanner 默认缓冲区只有 64KB，遇到超长日志行或大块二进制数据会直接报 scanner.ErrTooLong，导致索引中断。它也不支持从任意偏移开始扫描——必须配合 io.ReadSeeker 手动跳过已处理部分。
使用场景：纯文本日志（如 JSON 行、Nginx access log），每行独立可索引。
立即学习“go语言免费学习笔记（深入）”；
- 初始化时用
file.Seek(offset, io.SeekStart)定位，再传给bufio.NewReader - 调用
scanner.Split(bufio.ScanLines)显式指定分隔逻辑，避免默认行为误判 - 捕获
scanner.Err()并区分io.EOF（正常）和真实错误（如权限变更）
偏移量持久化该存哪里、怎么读写才不丢数据
把偏移量写进本地文件最简单，但直接 os.WriteFile 有风险：写入中途崩溃会导致偏移量损坏，下次启动就读错位置。而且多个进程并发写同一索引文件会冲突。
性能影响：每次更新都 fsync 会拖慢吞吐，但不 fsync 又可能丢最后几 KB 索引进度。
- 用临时文件 +
os.Rename原子替换，例如写到index.offset.tmp再重命名为index.offset - 写完立刻调用
f.Sync()，别依赖Close()—— 它不保证元数据落盘 - 读取时用
os.ReadFile而非流式读，避免读到半截损坏的数字（比如只写入了 "1234" 中的 "12"）
Linux 下用 inotify 替代轮询的边界条件
fsnotify 库底层用 inotify，但它只通知“文件被修改”，不告诉你改了多少字节、从哪开始。如果应用本身是写文件的同一进程，IN_MODIFY 事件可能在写入中途就触发，此时 Stat().Size 还没更新，你去读会阻塞或读到脏数据。
兼容性影响：Docker 容器内默认禁用 inotify，K8s Pod 需加 securityContext.sysctls 或换轮询；macOS 必须用 fsevents，行为不一致。
- 收到
IN_MODIFY后，仍要 sleep 几毫秒再Stat()，等内核完成写入提交 - 对追加写场景，优先监听
IN_CLOSE_WRITE（关闭写入句柄时触发），更稳 - 永远保留 fallback 轮询逻辑，
inotify实例数有限，大目录下容易too many open files
偏移量不是时间戳，它依赖文件内容不变性。如果上游程序做了 truncate 或 rewrite，旧偏移直接失效——这点最容易被忽略，也最难自动修复。
