inotify_add_watch返回-1且errno=enospc是因系统限制每个用户inotify实例总数，默认128，需调大/proc/sys/fs/inotify/max_user_instances并确保及时调用inotify_rm_watch或close。
inotify_add_watch 返回 -1 且 errno=ENOSPC 怎么办
这是 inotify 最常卡住人的第一道坎：监控句柄数超限，不是代码写错了，是系统限制了每个用户能创建的 inotify 实例总数。
典型现象是反复调用 inotify_add_watch 突然失败，errno 打印出来是 ENOSPC（注意不是磁盘空间满，而是 inotify 资源耗尽）。
- 查当前限制：
cat /proc/sys/fs/inotify/max_user_instances，默认常为 128 - 临时提高（需 root）：
sudo sysctl fs.inotify.max_user_instances=512 - 永久生效：往
/etc/sysctl.conf加一行fs.inotify.max_user_instances = 512 - 更关键的是——别漏掉
inotify_rm_watch或close(inotify_fd)，尤其在异常路径或子目录递归监控时容易忘记清理
监控子目录需要递归调用 inotify_add_watch 吗
需要，inotify 本身不支持递归监控。你对父目录加 watch，只会收到该目录下直接子项的事件（比如新建一个子目录），但不会自动监控那个子目录内部的变化。
所以“监控整个目录树”的逻辑必须自己实现：监听到 IN_CREATE | IN_ISDIR 事件后，立刻对新出现的子目录再调用一次 inotify_add_watch。
- 注意判断
event->mask & IN_ISDIR再决定是否递归添加，否则会把文件也当目录去 open 失败 - 避免重复添加：用
std::map或std::set记录已监控的路径，防止同一目录被多次 watch 导致资源浪费 - 删除子目录时记得同步调用
inotify_rm_watch，否则残留 watch 句柄会持续占用限额
read(inotify_fd, buf, len) 返回值小于 sizeof(struct inotify_event) 怎么处理
这说明内核返回了不完整的事件结构体，常见于缓冲区太小或事件爆发式涌入。不能直接按固定偏移解析，否则会读错字段甚至越界。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
inotify_event 是变长结构体：len 字段表示实际事件名长度，整个事件大小是 sizeof(struct inotify_event) + event->len。
- 每次
read后必须用event->len计算下一个事件起始位置，不能硬写event + 1 - 缓冲区大小建议至少设为
4096（一页），太小会导致频繁截断；但也不要盲目设极大值，read是阻塞的，大缓冲可能拖慢响应 - 遇到
read返回值为 0？那是 inotify fd 被 close 了，通常意味着上层主动释放或进程异常退出
监听 IN_MOVED_TO 但收不到重命名事件？
重命名（mv）操作在 inotify 中拆成两个事件：IN_MOVED_FROM 和 IN_MOVED_TO，且共用同一个 cookie 值。只监听其中一个，就会漏掉关联性。
如果你只关心“文件被重命名了”，必须同时监听这两个 mask，并靠 cookie 匹配成对事件。
- 别用
IN_MOVE宏——它只是IN_MOVED_FROM | IN_MOVED_TO的简写，实际注册时仍要显式包含两者 -
cookie为 0 表示单向移动（如跨文件系统 mv，本质是 copy+unlink），此时只会有IN_MOVED_TO或只有IN_MOVED_FROM - 注意：
IN_MOVED_TO的name字段是目标文件名，但若重命名发生在被监控目录之外（比如从外面 mv 进来），name才有效；否则可能为空
真正难的不是怎么注册 watch，而是怎么在大量事件涌入时不丢、不错、不重复、不泄漏句柄——尤其是程序长期运行时，inotify 的资源生命周期管理比事件解析更易出问题。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
