最轻量可靠的方式是inotify监听IN_MODIFY和IN_MOVED_TO事件，并同时监控文件自身IN_MOVE_SELF及父目录IN_MOVED_TO以应对logrotate轮转；跨平台需轮询stat组合判断st_ino与st_size变化；读取时用滚动缓冲区按行解析，避免丢行或粘包。
用 inotify 监听单个文件变化（Linux）
Linux 下最轻量、最可靠的方式就是 inotify，它不轮询、不占 CPU，内核级事件通知。关键不是监听“内容变化”，而是监听 IN_MODIFY（写入）和 IN_MOVED_TO（日志轮转常见场景）。
常见错误是只注册 IN_MODIFY，结果日志被 logrotate 重命名 + 新建后就收不到新内容了——必须同时监听源路径的 IN_MOVE_SELF 和父目录的 IN_MOVED_TO 才能覆盖轮转。
- 用
inotify_init1(IN_CLOEXEC)创建句柄，避免 fork 后泄漏 - 对目标文件调用
inotify_add_watch(fd, path, IN_MODIFY | IN_MOVE_SELF) - 对其父目录再加一个 watch：
inotify_add_watch(fd, dirname(path), IN_MOVED_TO) -
read()返回的struct inotify_event中，wd字段要和你注册的 watch descriptor 对比，mask判断事件类型，len非零才读name
跨平台方案：轮询 + stat 检查（Windows/macOS/Linux 通用）
Windows 没有 inotify，macOS 的 FSEvents API 复杂且不暴露文件级修改粒度，所以轮询仍是唯一可预测的兜底方式。重点不在“多快”，而在“怎么判断真变了”。
只比对 st_size 或 st_mtime 都不可靠：st_mtime 在追加写时可能不变（缓冲未刷盘），st_size 在截断或覆盖写时会误判。真正安全的做法是组合检查：
立即学习“C++免费学习笔记（深入）”；
- 先读当前
stat()，记录st_size和st_ino - 下次检查时，若
st_ino变了 → 文件被替换（如 logrotate 的 create+rename），需重新打开 - 若
st_ino不变但st_size > last_size→ 追加写，从last_size处lseek()继续读 - 若
st_size → 被截断，按需处理（通常重置偏移为 0）
轮询间隔设成 100ms～1s 即可，太短无意义，太长延迟高；用 nanosleep() 而非 usleep() 避免信号中断导致精度丢失。
读取新增内容时如何避免丢行、粘包
监听到变化只是第一步，真正难的是把新字节流准确切分成“一行一行”的内容。直接 read() 到缓冲区再按 \n 切，会遇到两种典型问题：
- 一行没读完（缓冲区满但没遇到换行符）→ 下次读到开头不是完整行
- 一次
read()读到多行（比如日志批量刷盘）→ 不能整块当一行处理
解决方案是维护一个滚动缓冲区（ring buffer 或 std::string）：
- 每次
read()追加到缓冲区末尾 - 反复查找
\n，每找到一个就把前面到该位置的子串作为一行提取出来，缓冲区前移 - 剩余部分保留在缓冲区头部，等下次读入继续拼接
- 注意处理
\r\n和\n混用情况，日志里常见；提取时统一 trim 掉\r
别用 std::getline() 直接读文件描述符——它内部会做自己的缓冲，和你的事件驱动逻辑不同步，容易漏事件或重复读。
文件被删除或权限变更时的静默失败
监听中的文件被 rm 或 chmod 后，inotify 仍会发 IN_DELETE_SELF 或 IN_IGNORED 事件，但轮询方式完全感知不到——stat() 会返回 -1 且 errno == ENOENT 或 EACCES。
这意味着你必须在每次检查前验证文件是否仍可访问：
- 轮询路径：每次
stat()前先access(path, R_OK)，失败则记录并尝试重新监听（比如等待文件重建） -
inotify路径：收到IN_IGNORED后，不要继续read()，应关闭 fd、清理 watch，并根据业务决定是否重建监听 - 尤其注意容器环境：挂载点被 unmount 会导致
stat()卡住（默认行为），加AT_NO_AUTOMOUNT标志或设超时
没人会一直盯着日志文件是否存在，真正的健壮性体现在“消失后再出现”能否自动恢复——这需要状态机管理，而不是一锤子监听。
