绝大多数场景该用event，仅流式组合、错误恢复或跨异步源聚合时才用IObservable；event适用于UI交互、属性通知等，开销低且语义清晰；IObservable适用于需Where、Throttle、CombineLatest等操作的数据流加工场景。
在 C# 里，观察者模式不是“怎么实现”的问题，而是“用 event 还是 IObservableevent，只有明确需要流式组合、错误恢复或跨异步源聚合时，才该上 IObservable<t></t>。
什么时候必须用 event 而不是 IObservable
UI 交互、属性变更通知（INotifyPropertyChanged）、文件系统事件（FileSystemWatcher.Changed）这些都该用 event。它开销低、语义清晰、和框架天然对齐。
-
event是语言级语法糖，编译后就是委托字段 +add/remove方法，没有额外引用计数或生命周期管理负担 - 不要把
IObservable<t></t>当成“高级版 event”硬套进按钮点击逻辑里——会引入订阅泄漏、冷热源混淆、线程调度误判等真实故障 - 发布者生命周期短于订阅者时（比如临时 ViewModel 订阅长期服务），
event更安全：没IDisposable约束，也不依赖 Rx 的资源清理链 - 触发写法必须是
OnChanged?.Invoke(this, args)，别写if (OnChanged != null) OnChanged(...)——中间可能被其他线程取消订阅，直接抛NullReferenceException
什么时候必须用 IObservable
当你需要对多个数据流做 .Where()、.Throttle()、.Retry()、.Catch() 或合并（Observable.CombineLatest）时，IObservable<t></t> 才不可替代。
- 典型场景：传感器数据滤波、用户操作行为流分析、实时行情聚合；不是“通知谁”，而是“怎么加工再投递”
-
IObservable<t></t>默认是“冷”的——每次Subscribe()都触发新执行；误以为“订阅就能收到历史事件”是高频坑点 - 必须显式管理生命周期：
IDisposable subscription = source.Subscribe(...); subscription.Dispose();，漏掉就内存泄漏 - 别手写
IObservable<t></t>实现类；要用Observable.Create()或Subject<t></t>，否则极易写出线程不安全或资源泄漏代码
event 和 IObservable 怎么桥接（真要混用时）
只在已有成熟 event 接口（如第三方控件的 Click）但下游要用 Rx 处理时才桥接。别为了“看起来更函数式”而转。
- 正确方式是
Observable.FromEventPattern<EventArgs>(h => button.Click += h, h => button.Click -= h) - 别手动在
Subscribe里写+=，否则无法保证取消订阅时同步清理 - 桥接后要注意调度上下文：UI 控件事件默认在 UI 线程触发，但
Subscribe回调可能跑在后台线程，需用.ObserveOn(SynchronizationContext.Current)显式切回 - 桥接对象本身不解决生命周期问题——如果按钮被 GC，但桥接的
IObservable还被持有，照样泄漏
最常被忽略的其实是“冷热源混淆”：event 是热广播，IObservable 默认是冷执行。强行让二者语义对齐，比选错方案更容易出线上事故。
