必须用 ObservableCollection 的唯一场景是集合直接或间接参与数据绑定（如 ItemsSource），否则 List 更高效；它不监听元素属性变化，需元素自身实现 INotifyPropertyChanged。
需要绑定到 WPF/UWP 界面的集合，就用 ObservableCollection<t></t>；纯后台计算、高频操作或不需要 UI 响应的场景，别用它——List<t></t> 更轻、更快、没副作用。
什么时候必须用 ObservableCollection 而不是 List
核心判断标准只有一条：这个集合是否直接或间接参与了数据绑定（比如作为 ItemsSource 绑定到 ListBox、DataGrid 或 ComboBox）。一旦绑定了，List<t></t> 就会“失声”——你调用 Add()、Remove()，UI 完全无反应。
- WPF 中绑定
ListBox.ItemsSource = mylist;后，mylist.Add("x")不刷新界面 → 这是List<t></t>的正常行为，不是 bug -
ObservableCollection<t></t>会自动触发CollectionChanged事件，WPF 绑定引擎监听到后立即更新控件 - 即使你当前没绑定，但未来可能暴露给 UI（比如 MVP/MVVM 架构中 ViewModel 层的属性），也建议一开始就用
ObservableCollection<t></t>，避免后期重构 - 注意：它不监听集合内元素的属性变化——比如
Person.Name改了，UI 不会自动更新，除非Person自身实现INotifyPropertyChanged
如何正确注册和响应 CollectionChanged 事件
事件回调里要区分 e.Action 类型，且必须检查 e.NewItems 和 e.OldItems 是否为 null，否则容易触发空引用异常。
-
e.Action == NotifyCollectionChangedAction.Add：只看e.NewItems，它是IList，需遍历 -
e.Action == NotifyCollectionChangedAction.Remove：只看e.OldItems -
e.Action == NotifyCollectionChangedAction.Replace：e.OldItems和e.NewItems都非空 -
e.Action == NotifyCollectionChangedAction.Reset：整个集合被清空或重置（如Clear()、new ObservableCollection<t>(other)</t>），此时e.OldItems和e.NewItems均为null，不能遍历
示例写法：
collection.CollectionChanged += (s, e) =>
{
switch (e.Action)
{
case NotifyCollectionChangedAction.Add:
foreach (var item in e.NewItems) { /* 处理新增 */ }
break;
case NotifyCollectionChangedAction.Remove:
foreach (var item in e.OldItems) { /* 处理删除 */ }
break;
case NotifyCollectionChangedAction.Reset:
// 清空逻辑，不访问 e.NewItems/e.OldItems
break;
}
};批量添加时性能差？别直接 for 循环 Add
每次调用 Add() 都会触发一次 CollectionChanged 事件。100 次 Add() = 100 次 UI 更新通知，WPF 可能卡顿甚至崩溃。
- 不要这样写：
foreach (var x in data) collection.Add(x); - 推荐做法：先构造好数据，再一次性赋值：
collection = new ObservableCollection<t>(data);</t>—— 构造函数内部只触发一次Reset事件 - 如果必须复用原实例（比如已有事件监听器），可用第三方
ObservableRangeCollection<t></t>（来自 MvvmCross/ReactiveUI），它提供AddRange()方法，只发一次事件 - 自定义封装也行，但要注意线程安全：WPF 的
CollectionChanged必须在 UI 线程触发，跨线程调用需用Dispatcher.Invoke
序列化失败、元素属性不更新？两个常见盲区
Newtonsoft.Json 默认无法序列化 ObservableCollection<t></t> 内部元素的私有字段，也不会自动处理 INotifyPropertyChanged 监听逻辑。
- 序列化时字段丢失：确保元素类型（如
MotionIntervalSegmentation）的每个 public 属性都加了[DataMember]（使用DataContractSerializer）或[JsonProperty]（使用JsonConvert） - 元素属性变更不通知 UI：仅靠
ObservableCollection不够，元素自身必须实现INotifyPropertyChanged，且在属性 setter 中调用OnPropertyChanged() - 别试图让
ObservableCollection监听子元素变化——它只管“集合结构”，不管“元素内容”。真有这需求，得继承它并重写OnCollectionChanged，手动注册/注销子元素的PropertyChanged事件
真正难的从来不是怎么写，而是想清楚：你要响应的是“集合变了”，还是“集合里的某个对象的某个属性变了”——这两者的技术路径完全不同。
