c#如何使用ObservableCollection_c#ObservableCollection最全用法总结

划重点：ObservableCollection 的唯一使用场景是集合直接或间接参与数据绑定（比如 ItemsSource），否则 List 更高效；它不监听元素属性变化，必须由元素自身实现 INotifyPropertyChanged。

需要绑定到 WPF/UWP 界面的集合，就用 ObservableCollection；纯后台计算、高频操作或不需要 UI 响应的场景，别用它——List 更轻、更快、没副作用。这基本上是共识，但真正落笔时还是会踩坑，比如序列化、批量操作、事件处理这些细节，稍不注意就炸。

什么时候必须用 ObservableCollection 而不是 List

核心判断标准只有一条：这个集合是否直接或间接参与了数据绑定（比如作为 ItemsSource 绑定到 ListBox、DataGrid 或 ComboBox）。一旦绑定了，List 就会“失声”——你调用 Add()、Remove()，UI 完全无反应。

• WPF 中绑定 ListBox.ItemsSource = mylist; 后，mylist.Add("x") 不刷新界面 → 这是 List 的正常行为，不是 bug
• ObservableCollection 会自动触发 CollectionChanged 事件，WPF 绑定引擎监听到后立即更新控件
• 即使你当前没绑定，但未来可能暴露给 UI（比如 MVP/MVVM 架构中 ViewModel 层的属性），也建议一开始就用 ObservableCollection，避免后期重构
• 注意：它不监听集合内元素的属性变化——比如 Person.Name 改了，UI 不会自动更新，除非 Person 自身实现 INotifyPropertyChanged

如何正确注册和响应 CollectionChanged 事件

事件回调里要区分 e.Action 类型，且必须检查 e.NewItems 和 e.OldItems 是否为 null，否则容易触发空引用异常。很多新手直接遍历 e.NewItems，结果碰上 Reset 动作直接炸裂。

• 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(other)），此时 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 可能卡顿甚至崩溃。这是新手最容易掉进去的坑——明明数据加载很快，UI 却卡得像幻灯片。

• 不要这样写：foreach (var x in data) collection.Add(x);
• 推荐做法：先构造好数据，再一次性赋值：collection = new ObservableCollection(data); —— 构造函数内部只触发一次 Reset 事件
• 如果必须复用原实例（比如已有事件监听器），可用第三方 ObservableRangeCollection（来自 MvvmCross/ReactiveUI），它提供 AddRange() 方法，只发一次事件
• 自定义封装也行，但要注意线程安全：WPF 的 CollectionChanged 必须在 UI 线程触发，跨线程调用需用 Dispatcher.Invoke

序列化失败、元素属性不更新？两个常见盲区

Newtonsoft.Json 默认无法序列化 ObservableCollection 内部元素的私有字段，也不会自动处理 INotifyPropertyChanged 监听逻辑。这两点经常被忽视，导致线上数据丢了、UI 不刷新，排查半天才发现是序列化标记没加。

• 序列化时字段丢失：确保元素类型（如 MotionIntervalSegmentation）的每个 public 属性都加了 [DataMember]（使用 DataContractSerializer）或 [JsonProperty]（使用 JsonConvert）
• 元素属性变更不通知 UI：仅靠 ObservableCollection 不够，元素自身必须实现 INotifyPropertyChanged，且在属性 setter 中调用 OnPropertyChanged()
• 别试图让 ObservableCollection 监听子元素变化——它只管“集合结构”，不管“元素内容”。真有这需求，得继承它并重写 OnCollectionChanged，手动注册/注销子元素的 PropertyChanged 事件

真正难的从来不是怎么写，而是想清楚：你要响应的是“集合变了”，还是“集合里的某个对象的某个属性变了”——这两者的技术路径完全不同。