Observable.FromEventPattern 是最安全的 UI 事件订阅方式，需显式传入 add/remove 委托，WPF 用泛型重载，WinForms 注意 EventHandler 类型，订阅后必须 Dispose 或用 using 管理生命周期。
如何用 Observable.FromEventPattern 订阅 UI 事件
WinForms 或 WPF 中直接订阅事件（如 Button.Click）会带来手动取消订阅的麻烦，容易内存泄漏。Observable.FromEventPattern 是最常用、最安全的起点，它把 .NET 事件自动转为可组合的 IObservable<t></t>。
实操建议：
- 必须传入事件的
addHandler和removeHandler委托，不能只写事件名；WPF 推荐用泛型重载，避免反射开销 - 对 WinForms 的
Control.Click，要传EventHandler类型，不是EventArgs - 订阅后务必调用
Dispose()或用using（配合ConnectableObservable或RefCount()更稳妥）
var clickStream = Observable.FromEventPattern<EventHandler, EventArgs>(
h => button.Click += h,
h => button.Click -= h);
Throttle 和 Debounce 在输入场景中怎么选
两者都用于抑制高频事件（比如 TextBox.TextChanged），但触发时机不同：Throttle 在「最后一次触发后等待指定时长」才发出，Debounce 是「每次触发都重置计时器，只在静默期结束后发最后一次」。实际效果几乎一样，但语义和底层实现不同 —— Rx.NET 当前版本中 Debounce 是推荐用法，Throttle 已标记为过时（obsolete）。
常见错误：
适用于用户提出以下需求时：“构建赢回活动（win-back campaign）”、“重新激活已流失订阅者（re-engage lapsed subscribers）”、“执行重新授权 / 重新同意（re-permission / re-consent）清理”或“清理无效联系人列表（sunset my dead list）”；输出一个闭环式再激活方案——包括：流失用户群组（lapsed-cohort）定义、分阶段优惠阶梯（staged offer ladder）、重新授权（re-consent / re-p
- 用
Throttle处理搜索框输入，结果发现用户快速连敲几个字后没响应 —— 因为它在第一次按键后就开始计时，后续按键不重置 - 没指定
Scheduler参数，默认走ThreadPool，导致 UI 线程更新失败（需接ObserveOn(SynchronizationContext.Current)）
textBox.TextChanged
.ToObservable()
.Debounce(TimeSpan.FromMilliseconds(300))
.ObserveOn(SynchronizationContext.Current)
.Subscribe(_ => Search());
为什么 Subject<t></t> 容易引发线程安全问题
Subject<t></t> 是可同时作为 IObservable<t></t> 和 IObserver<t></t> 的“桥梁”，但它本身不是线程安全的 —— 多个线程同时调用 OnNext 可能导致异常或数据丢失，尤其在事件回调 + 异步任务混合场景下（比如按钮点击触发 HTTP 请求，请求完成后再 OnNext）。
替代方案更可靠：
- 优先用
AsyncSubject<t></t>（只发最后一次值，适合单次结果）或ReplaySubject<t></t>（带缓冲，可设大小和时间窗口） - 若必须用
Subject，用Synchronize()包装：new Subject<int>().Synchronize()</int> - 更彻底的做法是避开
Subject，改用Observable.Create封装异步逻辑，由 Rx 控制生命周期
如何让 Rx 流在异常后继续运行而不是终止
Rx 流默认遇到异常就调用 OnError 并终止订阅 —— 这和传统 try/catch 不同，容易让人误以为“流挂了”。关键是要在源头或中间环节拦截异常，用 Catch 或 Retry 恢复。
使用注意点：
-
Catch接收一个异常并返回新的IObservable<t></t>，常配合Empty()或Return(default)吞掉错误 -
Retry会重订阅整个源，不适合有副作用的操作（比如重复提交表单）；RetryWhen更可控，可用Delay或指数退避 - 不要在
Subscribe的OnError回调里“忽略异常”，这只会让流真正结束
Observable.FromAsync(() => httpClient.GetStringAsync(url))
.Catch(Observable.Return(string.Empty))
.Subscribe(result => Console.WriteLine(result));
实际项目里最常被忽略的是调度上下文切换和资源释放时机 —— 尤其在长时间存活的 ViewModel 中，一个没 Dispose 的 Subscription 就足以让整个页面无法 GC。 
