FileSystemWatcher为什么会在短时间内触发多次Changed事件
因为操作系统对文件系统的底层通知机制（如Windows的ReadDirectoryChangesW）本身就会为一次逻辑操作发出多个底层事件——比如保存一个文本文件，可能依次触发
Created、
Changed（写入）、
Changed（属性更新）、
Renamed（临时文件替换），甚至同一类事件（如
Changed）被拆成多次调用。这不是C#的bug，而是FSW忠实地转播了系统信号。
常见诱因包括：编辑器自动保存、IDE编译输出、Git钩子写入、.NET热重载、防病毒软件扫描等。你看到的“多次触发”，往往对应真实发生的多次
WriteFile或
SetFileAttributes系统调用。
用Timer做简单去抖（Debounce）是最直接的方案
核心思路：不立即处理事件，而是启动一个短时定时器（比如300ms），每次收到新事件就重置它；只有定时器自然到期时才真正执行业务逻辑。这能有效合并连续写入、保存、覆盖等行为。
System.Timers.Timer比
System.Threading.Timer更易管理生命周期，且支持
AutoReset = false务必在
Timer.Elapsed中检查
Enable = true，避免多线程竞争导致重复执行 把待处理的
FileSystemEventArgs缓存到字段或
ConcurrentQueue，注意线程安全——FSW事件在后台线程触发 示例关键片段：
private readonly Timer _debounceTimer = new(300);
private FileSystemEventArgs _lastEvent;
public void OnChanged(object sender, FileSystemEventArgs e)
{
_lastEvent = e;
_debounceTimer.Stop();
_debounceTimer.Start();
}
private void OnTimerElapsed(object sender, ElapsedEventArgs e)
{
if (_debounceTimer.Enabled) return; // 防止竞态
_debounceTimer.Stop();
ProcessFileChange(_lastEvent); // 你的实际处理逻辑
}
区分事件类型和路径再合并，避免误吞关键变更
盲目合并所有
Changed事件会丢失语义——比如
Changed（内容）和
Changed（LastWriteTime）应区别对待，而
Created与后续
Changed通常属于同一操作链，但
Deleted必须立刻响应，不能等去抖。 优先合并同路径、同
ChangeType == WatcherChangeTypes.Changed的事件 对
WatcherChangeTypes.Created可设更短去抖窗口（100ms），确认不是临时文件残留 跳过对
.tmp、
~$、
.swp等临时文件后缀的监听，从源头减少干扰 设置
FileSystemWatcher.IncludeSubdirectories = false，除非真需要递归监控——子目录事件极易放大抖动
用Channel+BackgroundService实现高可靠事件流（.NET 6+）
当业务复杂、需顺序处理、或要求事件不丢失时，基于
Channel<filesystemeventargs></filesystemeventargs>构建异步管道比Timer更可控。它天然支持背压、取消和有序消费。 在
OnChanged里只做
await _channel.Writer.WriteAsync(e, cancellationToken)，零阻塞 后台服务从
_channel.Reader.ReadAllAsync()拉取事件，内部按需去抖、分组、过滤 注意
Channel.CreateBounded要设合理容量（如100），防止突发事件撑爆内存 务必在
Dispose中调用
_channel.Writer.Complete()，否则Reader会永远挂起
这种模式下，“合并”不再是硬性延迟，而是流式处理中的一个阶段：接收 → 缓存最近N秒事件 → 按路径/类型聚合 → 提交最终结果。真正的难点不在合并逻辑本身，而在如何定义“同一变更”的边界——比如编辑器保存一个.cs文件，究竟是算1次变更，还是应该等待编译完成后的.dll输出才算完整闭环？这取决于你的使用场景，没有银弹。
