filesystemwatcher的changed事件反复触发是正常行为，因编辑器保存、杀毒扫描等会导致多次lastwrite更新或重命名操作；仅设notifyfilters.lastwrite无法避免重复触发，推荐用concurrentdictionary+system.threading.timer实现每个文件路径的防抖处理。
FileSystemWatcher 的 Changed 事件反复触发不是 bug，是正常行为——尤其在文件保存、复制、编辑器写入（如 VS Code、Notepad++）时，一次“修改”常伴随多次 LastWrite 时间更新或临时文件重命名操作。直接在事件回调里处理业务逻辑，大概率导致重复加载、解析、写库等错误。
为什么 NotifyFilters.LastWrite 还会触发多次？
只设 NotifyFilters.LastWrite 能过滤掉 FileName、Attributes 等无关变更，但无法避免以下真实场景：
- 某些编辑器（如 Sublime Text）采用“写临时文件 + 原子重命名”方式保存，会先触发
Created，再触发Changed（甚至两次Changed） - Visual Studio 保存 .cs 文件时，可能先截断（
Truncate），再写入，导致两次LastWrite更新 - 杀毒软件或 OneDrive/Google Drive 同步客户端在后台扫描或同步时，也会触碰
LastWrite -
FileSystemWatcher本身是基于 Windows API 的异步通知，底层不保证“一次操作 → 一次事件”
禁用再启用 EnableRaisingEvents 是最简方案，但有硬伤
常见写法：fsw.EnableRaisingEvents = false; → 处理逻辑 → fsw.EnableRaisingEvents = true;。表面看能防重入，实际问题不少：
- 期间发生的其他文件事件（比如另一个文件被创建）会被完全丢弃，不可靠
- 如果处理逻辑抛异常，
EnableRaisingEvents可能永远卡在false，监控彻底失效 - 多线程下（如多个
FileSystemWatcher实例共用一个回调），EnableRaisingEvents是实例级开关，无法隔离单个文件 - 对高频目录（如日志目录），短时间大量文件变动会导致事件积压+开关抖动，反而更不稳定
推荐：用 Timer + 字典实现 per-file debounce
核心思路：每个文件路径独享一个延迟计时器，事件来时重置倒计时，仅当“该文件静默满 500ms”后才执行真正逻辑。线程安全用 ConcurrentDictionary，避免锁阻塞。
关键代码片段（无需第三方包）：
private readonly ConcurrentDictionary<string timer> _debounceTimers = new();
private const int DebounceMs = 500;
void OnChanged(object sender, FileSystemEventArgs e)
{
// 只处理 Changed，且确保文件存在（规避删除中途读取）
if (e.ChangeType != WatcherChangeTypes.Changed || !File.Exists(e.FullPath)) return;
// 每个文件路径对应一个 Timer
var timer = _debounceTimers.GetOrAdd(e.FullPath, _ => new Timer(_ =>
{
try
{
ProcessFile(e.FullPath); // 你的实际处理逻辑
}
finally
{
_debounceTimers.TryRemove(e.FullPath, out _);
}
}, null, Timeout.Infinite, Timeout.Infinite));
// 重置计时器：先 Stop，再 Change 到 500ms 后触发
timer.Change(DebounceMs, Timeout.Infinite);
}</string>
注意点：
- 不要用
System.Timers.Timer（自动跨线程，但回调可能并发）；推荐System.Threading.Timer，手动控制线程上下文 -
ProcessFile必须是幂等的——即使因异常未清理 timer，下次事件仍会重置，不会永久堆积 - 若需支持子目录，
e.FullPath要做路径归一化（如Path.GetFullPath），避免大小写或 ./../ 导致字典键不一致 - 内存泄漏风险：长期运行需定期清理已删除文件对应的 timer（可加
Deleted事件监听配合移除）
最后提醒：别忽略文件锁定和权限问题
即使 debounce 逻辑完美，ProcessFile 仍可能失败：
- 编辑器未释放文件句柄 →
File.OpenRead抛IOException: The process cannot access the file - UAC 或沙盒环境导致无权读取目标路径 → 需提前检查
Directory.GetAccessControl - 网络盘或符号链接路径行为异常 → 测试务必覆盖 UNC 路径（
\servershare）和mklink场景
真正健壮的监听，debounce 只解决“事件去重”，读取阶段的重试、超时、权限兜底，一个都不能少。
