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` 事件會被觸發，但它的事件處理程序會在當前事件處理程序完全執行完畢后才開始。
由于新的事件處理程序不在當前的事件處理上下文中，它不會再次進入同一個事件處理程序**，從而避免了遞歸。
?
