FileSystemWatcher 默认不监听子目录改动，需显式设置 IncludeSubdirectories = true；频繁触发需防抖去重；退出前须设 EnableRaisingEvents = false 并调用 Dispose()；读文件前应校验存在性与可访问性。
FileSystemWatcher 为什么监听不到子目录改动？
默认情况下 FileSystemWatcher 只监控指定路径的**直接子项**，不会递归监听子文件夹里的新增、修改或删除。这是最常被忽略的配置点。
必须显式设置 IncludeSubdirectories = true，否则哪怕你在 C:\Project 下启用了监听，C:\Project\src\Program.cs 的保存也不会触发事件。
实操建议：
- 初始化后立即设置
watcher.IncludeSubdirectories = true，别依赖构造函数参数 - 注意性能影响：深层嵌套+大量小文件时，可能引发
InternalBufferOverflowException，需调大InternalBufferSize（如设为 65536） - 若只关心特定子目录（如仅
logs/和config/），建议分别创建多个FileSystemWatcher实例，而非全开递归
Changed 事件频繁触发两次？怎么合并去重？
Windows 文件系统在保存文本文件等操作中，常先写临时文件再重命名/覆盖，导致 Changed 事件被连续触发多次（尤其是 LastWrite 时间戳变化），实际业务只需响应“最终稳定状态”。
不能靠 Thread.Sleep() 硬等，也不该在事件回调里加锁阻塞主线程。推荐用轻量级防抖（debounce）策略：
- 用
System.Threading.Timer或Task.Delay()延迟执行真正逻辑，每次新事件到来就取消前一个定时器 - 记录最后触发时间与文件路径，100–500ms 内同一文件的重复事件直接丢弃
- 避免监听
Created+Changed+Renamed全部事件——多数场景只订阅Changed并检查EventArgs.ChangeType == WatcherChangeTypes.Changed就够了
为什么程序退出后还在报错：“Cannot access a disposed object”？
FileSystemWatcher 是非托管资源，未正确释放时，后台线程可能仍在尝试触发已销毁对象的事件处理器，抛出 ObjectDisposedException 或访问已释放句柄的错误。
关键动作必须做：
- 在窗体关闭、服务停用或
Dispose()前，先调用watcher.EnableRaisingEvents = false - 再手动调用
watcher.Dispose()（或用using语句包裹） - 事件处理方法内部避免引用已生命周期结束的对象（如已
Close()的窗体控件），可用InvokeRequired+BeginInvoke安全更新 UI - 不要在静态事件处理器里捕获实例字段——容易造成内存泄漏和跨生命周期调用
同步执行 vs 异步回调：事件里能直接读文件吗？
可以，但有风险。当 Changed 事件触发时，文件可能正处于写入中间态（比如 VS 正在保存 .cs 文件），此时用 File.ReadAllText() 会抛 IOException: The process cannot access the file...。
安全做法是加一层存在性与可访问性校验：
- 先用
File.Exists(path)确认文件存在 - 用
try { using (var fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite)) { } }测试是否可读（不真读内容） - 仍失败则延迟重试（最多 2–3 次，间隔 50ms），避免死等
- 若需长期稳定同步（如配置热更新），建议搭配文件哈希比对或版本号字段，而非仅依赖时间戳
真正难处理的不是“怎么监听”，而是“怎么判断这次改动已经可靠完成”。Windows 文件操作本身没有原子提交语义，监听只是个信号，后续动作得自己兜底。
