inotify无法可靠捕获“写结束”事件，因其仅通过in_close_write通知可写fd关闭，不保证数据落盘；对重命名覆盖需监听目录的in_moved_to；强依赖落盘须用fsync+.ready文件等替代方案。
inotify 无法直接捕获“写结束”事件
Linux 的 inotify 接口本身没有 IN_CLOSE_WRITE 之外的“写完成”语义，而 IN_CLOSE_WRITE 仅在文件被**以可写方式打开且显式关闭**时触发——这不等价于“数据已落盘”或“应用写完”，更不是“写操作结束”的可靠信号。很多程序（如 vim、rsync、日志轮转工具）会先写临时文件再原子重命名，此时原文件根本不会触发 IN_CLOSE_WRITE。
监听 IN_CLOSE_WRITE 是最接近的可行方案
对单个普通文件监控写关闭行为，需用 inotify_add_watch 注册 IN_CLOSE_WRITE 标志。注意以下要点：
-
IN_CLOSE_WRITE只对当前已存在的文件有效；若文件被删除后重建，需重新添加 watch - 必须用
O_WRONLY或O_RDWR打开文件才能触发该事件；O_APPEND不影响，但只读打开不会触发 - 一次
write()调用后不触发，只有对应 fd 被close()时才发事件 - 多个进程同时写同一文件时，每个写进程关闭 fd 都会独立触发一次事件
示例关键片段：
int fd = inotify_init1(IN_CLOEXEC); int wd = inotify_add_watch(fd, "/path/to/file", IN_CLOSE_WRITE); // 后续 read() 从 fd 读取 inotify_event，检查 event->mask & IN_CLOSE_WRITE
遇到重命名/覆盖场景必须配合 IN_MOVED_TO 和目录监控
当目标文件可能被外部工具（如 logrotate、cp --sparse=always）通过“写新文件 + rename()”方式更新时，单纯监听文件本身完全失效。此时必须：
- 监听文件所在**目录**，而非文件路径本身
- 注册
IN_MOVED_TO | IN_CREATE，并过滤event->len > 0 && strcmp(event->name, "target_file") == 0 - 注意
IN_MOVED_TO在 rename 成功后立即触发，比任何 write 关闭都更贴近“新内容就绪”时刻 - 若需区分是覆盖还是追加，得结合文件大小、mtime 或 inode 变化做二次判断
真正需要“写入完成且落盘”得绕过 inotify
如果业务逻辑强依赖“数据已刷到磁盘”（比如审计、备份同步），inotify 从设计上就不满足。可行替代路径包括：
- 让写入方主动在写完后
fsync()+ 创建一个.ready空文件，监控该空文件的IN_CREATE - 用
fanotify（需 root）拦截写系统调用并检查FAN_OPEN_EXEC或FAN_EVENT_ON_CHILD，但复杂度陡增 - 定期
stat()检查 mtime+size 是否稳定（简单但有延迟和竞态） - 改用日志类库（如
spdlog）内置的 flush hook，而非依赖内核事件
inotify 是轻量文件事件通知机制，不是 I/O 完成通知器。把“写结束”理解为“fd 关闭”已是它能力的边界，越界使用只会陷入事件丢失或误触发的调试泥潭。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
