linux下用inotify监听目录变化最直接：需调用inotify_init()、inotify_add_watch()和read()逐个解析struct inotify_event，注意缓冲区至少4096字节、name字段仅含文件名、递归需手动遍历子目录并分别添加watch。
Linux下用inotify监听目录变化最直接
inotify是Linux内核原生支持的文件系统事件机制，不需要第三方库，开销低、响应快。它适合监控单个目录（不递归）或有限层级的子目录。
关键函数是inotify_init()、inotify_add_watch()和read()阻塞读取事件。注意read()返回的是二进制事件流，必须按struct inotify_event结构逐个解析，不能当字符串处理。
- 每个watch只能绑定一个目录，递归监控需手动遍历子目录并为每个目录调用
inotify_add_watch() -
IN_MOVED_TO和IN_CREATE都可能对应新建文件，但前者还涵盖重命名场景；若只关心“新增”，建议同时监听这两个掩码 - 缓冲区大小要设够：
read(fd, buf, sizeof(buf))中buf至少4096字节，否则事件可能被截断丢弃 - 事件中的
name字段仅含文件名，不含路径；拼接完整路径时务必用strcat或std::string拼接原始监控路径，别漏掉/
Windows上用ReadDirectoryChangesW必须用异步IO
Windows没有类inotify的轻量接口，ReadDirectoryChangesW是官方推荐方式，但它**必须配合重叠IO（OVERLAPPED）使用**，同步调用会立即返回失败或阻塞失效。
常见错误是传入NULL作为lpOverlapped参数——这会导致函数返回FALSE且GetLastError()为ERROR_IO_PENDING，但程序没做后续等待，直接以为监听失败。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 每次调用前需重置
OVERLAPPED结构体的hEvent或清零Internal/InternalHigh字段，否则重复调用可能出错 -
dwNotifyFilter选FILE_NOTIFY_CHANGE_FILE_NAME | FILE_NOTIFY_CHANGE_LAST_WRITE覆盖改名和内容修改，但FILE_NOTIFY_CHANGE_DIR_NAME才捕获子目录增删 - 回调或
GetOverlappedResult()返回的变更记录是变长结构，需用NextEntryOffset字段链式遍历，不能简单按固定偏移取下一个 - 缓冲区建议至少
8192字节；太小会导致ERROR_NOTIFY_ENUM_DIR错误，意味着事件被截断
跨平台方案选libuv比Boost.Filesystem更实用
Boost.Filesystem没有内置文件监控能力，Boost.Asio也不直接支持。真正成熟跨平台的选择是libuv——Node.js底层IO库，C接口简洁，Windows走ReadDirectoryChangesW，Linux/macOS走inotify/kqueue，封装了平台差异。
初始化后调用uv_fs_event_t相关API即可，但要注意：它默认**不递归监控子目录**，且Linux下对符号链接目录的行为未定义（可能跳过或报错）。
-
uv_fs_event_start()的回调函数中，filename参数在Windows下可能为空（尤其重命名场景），需结合events标志位判断动作类型 - 启动监控前确保目标路径存在且可访问，
uv_fs_event_start()失败时uv_strerror(uv_last_error(loop))才能看到真实原因（比如权限不足） - 不要在回调里做耗时操作（如读文件内容），应投递到线程池或另起任务；libuv的fs_event回调运行在IO线程，阻塞会影响其他事件
避免误报和漏报的关键细节
文件监控不是“看到什么就报什么”，编辑器保存、Git拉取、IDE构建都会触发大量中间事件。比如VS Code保存文件常先写临时文件再rename()，这时IN_MOVED_TO比IN_CREATE更可靠。
- 对同一路径的连续事件（如
IN_CREATE紧接IN_MODIFY）要做去重或合并，否则一个保存动作可能触发两次通知 - 监控进程重启时，无法感知上次运行期间发生的变更，需额外设计快照比对逻辑（比如记录
stat()的st_mtime和st_ino） - Linux下
inotify有用户级限制：/proc/sys/fs/inotify/max_user_watches默认常为8192，监控大量目录时容易触发No space left on device错误，需提前增大该值 - macOS的
FSEvents不保证事件顺序，且对硬链接、符号链接行为特殊；如果业务强依赖顺序，得在应用层加时间戳+序列号做排序
真正难的不是注册监听，而是区分哪些变动该响应、哪些该忽略，以及如何应对监控中断或事件积压。这些逻辑没法靠库自动解决，得根据具体业务补全。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
