UniRx CombineLatest()返回冷/热可观测对象？Subscribe内OnNext调用失效原因

UniRx中CombineLatest的冷热属性判定 #

CombineLatest本身不存在固定的冷热类型，属性完全由传入的上游源决定。
从操作符的核心实现逻辑看，它的封装本质是冷的：只有当下有观察者订阅返回的序列时，它才会去订阅所有传入的上游源，执行组合映射逻辑；没有下游订阅者时，它不会主动获取上游的推送数据，也不会触发任何计算。
即便你传入的上游是本身留存最新值、支持多播的热类型（比如代码中使用的Subject），这只会让CombineLatest被订阅时能快速拿到上游留存的最新值完成组合，不会改变它本身的冷封装属性。

第二种写法无法触发的根本原因 #

问题的核心和CombineLatest的冷热属性无关，是链路中嵌套的TakeLast(1)操作符语义，以及缺失流终止信号导致的逻辑死锁：

• TakeLast(1)的执行规则是：必须等整个上游流完全触发OnCompleted终止信号时，才会把缓存的最后一个OnNext值推送给下游订阅者。在收到终止信号前，它只会默默缓存上游传来的值，不会触发任何下游回调。
• 你代码中的两个上游都是长期存活的Subject，不存在自动触发OnCompleted的逻辑，意味着TakeLast(1)永远等不到流终止的信号，也就永远不会将缓存的组合值传递给Subscribe回调。回调本身都不会被执行，写在回调内部的positionStream.OnNext(a)自然永远无法触发。
• 你第一种能跑通的写法，是因为在订阅块外部手动调用了positionStream.OnNext(last_value)，这个动作是脱离TakeLast回调逻辑的独立外部触发，和Subscribe回调是否执行没有关系，因此看起来流程正常。

额外潜在风险 #

就算去掉TakeLast(1)直接在回调中调用OnNext，依然会触发新的问题：
当第一次收到CombineLatest的组合值时，回调会主动向positionStream推送新值；positionStream的新值又会触发CombineLatest的新一轮组合计算，生成新值推回下游回调，再次触发OnNext推送。这种没有边界的流输入输出循环，在同步调度场景下会直接造成栈溢出，在异步调度下会进入无限推送流程，违背响应式流的单向数据流原则。 #

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