Blazor WebAssembly中IObservable.Subscribe的OnNext非阻塞问题

这确实是Rx.NET的默认设计行为，核心差异源于调度器（Scheduler）的选择以及CombineLatest的推送逻辑：

为什么当前OnNext未返回就触发新的OnNext？ #

• 当你在OnNext回调中修改_deviceTypeFilterViewModel.Filters（假设这是Subject或类似可推送序列），CombineLatest会立即检测到新值并尝试推送组合后的结果。
• 如果当前执行OnNext的是即时调度器（ImmediateScheduler）（多数非UI场景的默认调度器），Rx.NET会直接在当前调用栈内同步执行新的OnNext回调，形成嵌套执行——也就是你看到的1 start后立刻启动2 start，所有嵌套回调执行完毕后才会依次输出end。

为什么Blazor Server中表现符合预期？ #

Blazor Server的同步上下文（SynchronizationContext）强制所有UI相关回调在单线程调度器上执行，这类调度器会将回调按顺序排队，必须等当前OnNext执行完毕后，才会启动下一个回调，因此不会出现嵌套执行的情况。

如何让非Blazor场景实现顺序执行？ #

若要保证OnNext回调串行执行，最可靠的方式是显式指定串行调度器：

_subscription = _observable.ClientData
    .CombineLatest(_deviceTypeFilterViewModel.Filters)
    .ObserveOn(EventLoopScheduler.Default) // 指定串行调度器，确保回调排队执行
    .Subscribe(OnNext, OnError);

如果是WPF/WinForms等UI场景，也可以使用对应平台的DispatcherScheduler来绑定到UI线程，同样能实现串行执行。

关键总结 #

• Rx.NET默认不保证OnNext回调的串行执行，需通过调度器显式约束。
• Blazor Server的同步上下文天然提供了串行执行环境，因此表现不同。
• 解决这类嵌套执行问题的核心是明确指定调度器，确保回调按预期顺序执行。

内容的提问来源于stack exchange，提问作者nuclear sweet