在 Node.js 环境下，实现文件系统监控以检测文件变化时，可以采用哪些主要方法？请说明不同方案的原理与适用场景。
考察说明
考查对 Node.js 文件系统监控机制的掌握程度，包括不同实现方式及其差异。
回答思路
- 【回答框架 1】Node.js 提供 fs.watch 和 fs.watchFile 两种核心 API。fs.watch 基于操作系统原生事件（如 inotify、FSEvents），监听目录或文件，缺点是事件信息依赖平台、可能重复触发。fs.watchFile 基于轮询，定期检查文件状态（mtime、size 等），稳定但开销较大，适用于需要跨平台一致性的场景。
- 【回答框架 2】fs.watch 回调参数包含 eventType 和 filename，但不同平台对 filename 的支持不一致（如 Linux 下可能为 null）。因此不能完全依赖 filename 参数，需结合路径拼接或使用第三方库统一行为。
- 【回答框架 3】对于复杂监控需求，可使用成熟库如 chokidar，它封装了 fs.watch 和 fs.watchFile，提供了统一的事件接口、过滤规则和配置选项，并处理了平台差异和事件重复问题。
- 【回答框架 4】监控大目录时，fs.watch 可能因文件句柄耗尽而失败，需要限制监听数量或采用分治策略。同时，需注意监听器泄漏问题，使用完要调用 close 方法释放资源。
- 【关键点 1】fs.watch 基于原生事件，开销小但跨平台行为不一致；fs.watchFile 采用轮询，兼容性好但性能开销较大。
- 【关键点 2】fs.watch 的 filename 参数在不同平台可能不同，不能依赖它进行精确处理。
- 【关键点 3】chokidar 等第三方库统一了事件接口，弥补了原生 API 的不足。
- 【关键点 4】监听大量文件时要注意资源限制，及时关闭不需要的监听器。
- 【关键点 5】对于只关心内容变化的场景，轮询方式（如 fs.watchFile）可能更可靠。
- 【易错点 1】fs.watch 在部分平台可能只触发单个事件，不提供具体改变的文件名，需结合其他信息补充。
- 【易错点 2】fs.watch 监听文件时，若文件被替换（rename），监听可能失效，需要重新监听。
- 【易错点 3】fs.watchFile 轮询间隔应合理设置，过短会消耗 CPU，过长会引入延迟。