inotify 是 Linux 内核中一套非常实用的文件系统事件监控机制，它允许应用程序实时捕获文件或目录的变化——比如文件被打开、关闭、修改、移动等。虽然功能强大，但它也存在一些局限性。以下是开发中需要特别关注的几个关键限制。

1. 第一个常见限制是监视数量有上限。每个进程可打开的文件描述符数量受内核参数 fs.inotify.max_user_watches 控制。一旦达到此上限，就无法创建新的监视实例。虽然该值可以调整，但前提是需要知道它的存在。

2. 第二个限制是事件队列可能溢出。inotify 在内核中维护了一个缓冲区用于排队事件，可以理解为一个小仓库。如果仓库满了，新事件要么被丢弃，要么挤掉旧事件。仓库大小由 fs.inotify.max_queued_events 决定，当事件生成速度过快时，很容易出现问题。

3. 第三个限制是每个文件描述符自身也有配额。每个被监视的文件或目录都拥有一个独立的小队列，队列满了同样会丢失事件。该配额对应 fs.inotify.max_user_instances。因此，即使只关注一个目录，也不能忽视其队列容量有限的问题。

4. 第四个限制是最令人头疼的：不支持递归监视。如果你想监视一个目录及其所有子目录的变化，inotify 不会自动递归处理。你需要手动为每个子目录单独创建监视实例。当目录层级很深或数量很多时，效率会显著下降。

5. 第五个限制是性能问题。尽管 inotify 整体开销较小，但在高并发、高负载场景下，如果挂载了成千上万个监视，系统性能仍会受到一定影响。因为每个监视都需要内核维护，数量越多，资源消耗越大。

6. 第六个限制是跨文件系统的问题。inotify 只能监控同一文件系统，跨文件系统时无法正常工作。如果需要跨文件系统监控，必须考虑其他方案，例如轮询或 FAM（File Alteration Monitor）。

7. 第七个限制是权限问题。应用程序必须拥有足够的系统权限才能访问被监视的文件或目录，否则 inotify 无法工作。这看似是常识，但新手容易忽略，导致代码无响应，排查半天才发现是权限不足。

8. 最后一个限制与内核版本有关。inotify 从 Linux 2.6.13 开始引入，如果系统内核太旧，可能根本不支持该功能。目前大多数主流发行版已超过此门槛，但老旧服务器上仍可能出现这个问题。

总的来说，inotify 虽然好用，但并非万能。在实际开发中，了解这些限制并根据实际情况灵活取舍，才是用好它的关键。例如，监视数量不够时可以扩大队列，目录层次多时可以考虑递归实现，性能扛不住时降低监控频率——这些调整并不复杂，但前提是清楚问题所在。