单例流组件因共享状态易导致用户数据污染，正确做法是按请求级作用域创建独立流实例或使用 defer 封装，避免全局单例共用。
单例流组件不是万能的缓存容器，它一旦被多个请求共用，就容易让不同用户的上下文数据互相污染。
单例流组件的本质是共享状态
流组件（比如基于 RxJS Subject、ReplaySubject 或某些框架封装的响应式流）若以单例方式注入（如 Angular 的 providedIn: 'root'、Spring 的 @Scope("singleton")），它的内部状态会被所有调用方共用。这意味着：一个请求写入的数据，可能被另一个并发请求读取到——尤其当流未及时清空、重置或隔离时。
- 典型场景：用户 A 触发搜索，流中塞入结果；用户 B 几乎同时发起请求，却收到 A 的缓存数据
- 更隐蔽的问题：流完成（complete）后未重新初始化，后续订阅直接拿到旧值或错误终止状态
- 副作用放大：若流内含异步操作（如 debounce、switchMap），不同请求的取消逻辑可能相互干扰
别把“流”当成“本地变量”来用
开发者常误以为“声明一个流变量 = 创建一个独立通道”，但单例类里的流字段只是对同一个对象的引用。它不随每次方法调用自动重建，也不因请求生命周期自动销毁。
- 错误写法：private result$ = new ReplaySubject
(1); 放在单例服务里 - 正确思路：需要隔离时，应在每次业务入口（如方法调用、HTTP 请求处理）中创建新流，或使用工厂函数生成独立实例
- 替代方案：改用 Observable.create() + defer() 封装逻辑，确保每次订阅都触发全新执行链
用“请求级作用域”代替“应用级单例”
真正需要跨组件通信或状态缓存时，优先考虑与请求/用户/会话绑定的作用域，而非全局单例。
- Angular 中可用 @Injectable({ providedIn: 'component' }) 让流服务随组件实例化
- 后端如 Spring 可结合 @Scope("request") 或 ThreadLocal 存储临时流上下文
- 前端也可借助路由参数、用户 ID 或请求 ID 作为 key，构建 Map
实现按需隔离
加一道“流快照”校验习惯
上线前，在关键流节点打日志或断言，检查当前流是否为空、是否已 error/completed、是否有意外残留值。这能快速暴露共享污染问题。
- 例如：订阅前 log(this.result$.observed) 和 this.result$.getValue()（若支持）
- 测试时模拟并发请求，观察流输出是否出现混杂、延迟或丢失
- 监控告警项可加入“流重放长度异常 > 1”或“非预期的多订阅者数”
