1.代码示例
private void LogInfoList_CollectionChanged(object? sender, NotifyCollectionChangedEventArgs e)
{
// 直接在这里修改集合会引发递归
if (e.Action == NotifyCollectionChangedAction.Add)
{
if (logInfoList.Count > 200)
{
logInfoList.RemoveAt(0); // 这里会触发 CollectionChanged
}
}
}修改为 `Dispatcher.BeginInvoke` 主要是为了避免在 `CollectionChanged` 事件处理程序中直接修改集合，导致递归调用的错误。`ObservableCollection` 会在修改时触发 `CollectionChanged` 事件，因此如果在事件处理程序中再次修改该集合，事件会被重新触发，这就可能导致无限递归或抛出错误。
具体原因和背景：
1. 避免递归调用：
在 `CollectionChanged` 事件处理程序中直接修改集合会触发另一次 `CollectionChanged` 事件。这样就会进入递归调用的死循环，导致栈溢出或其他问题。
例如，如果你在 `CollectionChanged` 中调用 `logInfoList.RemoveAt(0)`，这会导致 `logInfoList` 发生变化，从而再次触发 `CollectionChanged` 事件，导致程序再次执行该事件处理程序。通过 `Dispatcher.BeginInvoke` 延迟操作，我们确保修改集合的操作会等到事件处理程序执行完后再执行，从而避免递归触发事件。
2. UI 线程的调度：
`Dispatcher.BeginInvoke` 是用来在 UI 线程上执行任务的，它将操作推迟到下一个空闲时刻。即使你现在在处理事件，`Dispatcher.BeginInvoke` 也会让 `logInfoList.RemoveAt(0)` 的调用等到当前事件处理程序完成后执行。这样就不会发生集合修改时引发的事件触发问题。
工作原理：
-Application.Current.Dispatcher.BeginInvoke(new Action(() => { ... }))` 是一个异步方法，它会在 UI 线程的消息队列中排队，并在当前事件处理程序（如 `CollectionChanged`）完成后执行传入的操作。
- 这就确保了在执行 `RemoveAt(0)` 时不会再次触发 `CollectionChanged` 事件，从而避免了递归调用的错误。
例子说明：
假设你有一个 `logInfoList`，并且在 `CollectionChanged` 中添加了移除第一个元素的逻辑。如果直接在事件中调用 `RemoveAt(0)`，则会触发 `CollectionChanged`，导致无限循环：
private void LogInfoList_CollectionChanged(object? sender, NotifyCollectionChangedEventArgs e)
{
// 直接在这里修改集合会引发递归
if (e.Action == NotifyCollectionChangedAction.Add)
{
if (logInfoList.Count > 200)
{
logInfoList.RemoveAt(0); // 这里会触发 CollectionChanged
}
}
}为了避免这个递归，我们通过 `Dispatcher.BeginInvoke` 延迟对集合的修改操作：
private void LogInfoList_CollectionChanged(object? sender, NotifyCollectionChangedEventArgs e)
{
if (e.Action == NotifyCollectionChangedAction.Add)
{
// 使用 Dispatcher 来延迟移除第一个元素的操作
Application.Current.Dispatcher.BeginInvoke(new Action(() =>
{
if (logInfoList.Count > 200)
{
logInfoList.RemoveAt(0); // 这时不会触发 CollectionChanged 事件
}
}));
}
}总结：
通过 `Dispatcher.BeginInvoke` 延迟集合的修改，能够避免直接在事件处理过程中修改集合引发的递归调用问题，确保代码能稳定运行。
事件递归问题补充：
问题核心：
当 `RemoveAt(0)` 执行时，确实会触发一个新的 `CollectionChanged` 事件。由于使用了 `BeginInvoke` 延迟执行，所以这个新的事件处理程序会等当前的 `CollectionChanged` 事件处理完毕后才执行。那么，新的 `CollectionChanged` 事件在执行时会不会引发递归呢？
关键点：
1. 延迟执行的机制：
使用 `Dispatcher.BeginInvoke` 延迟执行操作，它不会在当前事件处理过程中立刻执行。而是将操作推入到消息队列中，待当前事件处理结束之后再执行。因此，新的 `CollectionChanged` 事件的处理程序 **不会在当前事件处理中执行**，也就是说，新的事件处理程序不会在递归的调用栈中。
2. 新的事件处理是否会递归：
当新的 `CollectionChanged` 事件处理程序执行时，它会触发一个新的事件，但是此时 **它已经不在当前事件的调用栈上。新的 `CollectionChanged` 事件是 **在当前事件完全结束后** 执行的，所以不会继续递归回到同一个事件处理程序。
3. 为什么不会递归：
递归的前提是事件在处理过程中不断触发新的事件，进入同一个事件处理程序。由于我们通过 `BeginInvoke` 延迟执行操作，新的事件触发是在当前事件处理程序 **执行完后**，并且事件处理程序本身已经结束，所以 **新的事件不会重新进入相同的事件处理程序**，从而避免了递归。
举个例子：
void CollectionChangedHandler(object sender, NotifyCollectionChangedEventArgs e)
{
Console.WriteLine("Collection changed!");
// 延迟删除第一个元素
Application.Current.Dispatcher.BeginInvoke(new Action(() =>
{
logInfoList.RemoveAt(0); // 删除第一个元素
}));
}1. 第一次 `CollectionChanged` 事件触发，进入 `CollectionChangedHandler`。
2. 在事件处理中，`BeginInvoke` 将 `RemoveAt(0)` 延迟执行，操作被排入消息队列中。
3. 第一次 `CollectionChanged` 事件处理完毕后，`BeginInvoke` 中的 `RemoveAt(0)` 被执行，触发新的 `CollectionChanged` 事件**。
4. 这个新的事件处理程序不会立即进入当前的 `CollectionChangedHandler`，因为当前事件处理已经结束。新的事件会等到当前的所有操作都完成后再执行。
5. 由于新的事件已经不在当前事件处理程序的上下文中，它不会再递归触发。
总结：
-新的 `CollectionChanged` 事件会被触发，但它的事件处理程序会在当前事件处理程序完全执行完毕后才开始。
由于新的事件处理程序不在当前的事件处理上下文中，它不会再次进入同一个事件处理程序**，从而避免了递归。