页面刷新时Observable已订阅的事件回调是否仍会触发？

这种情况是确定存在的，属于前端异步场景下的预期行为，不是代码bug。

原因说明 #

你贴的代码是典型的RxJS异步请求订阅逻辑，整条链路分两个完全解耦的阶段：

• 第一阶段：调用this.service.process()发起异步请求（通常是HTTP请求）。请求一旦从浏览器发出，就和当前页面的JS运行环境解绑了：只要浏览器主进程没有被强制终止，哪怕中途触发页面刷新，已经发出的请求大概率会在服务端走完完整的事务流程，服务端不会因为前端页面刷新就中断或回滚已经接收到的请求。
• 第二阶段：请求响应返回后，执行subscribe中注册的回调函数。这部分回调是存储在当前页面的JS内存空间中的，页面刷新的本质是浏览器销毁当前页面的整个JS执行上下文、清空所有页内内存、重新加载页面资源。只要上下文销毁动作发生在回调执行之前，注册的回调会被直接内存回收，完全没有执行机会，自然观测不到this.processed.emit()的运行。

补充：哪怕请求在刷新触发前的极短时间内已经拿到了响应结果，只要JS事件循环还没调度到这个回调任务，刷新带来的上下文销毁一样会清空待执行的任务队列，不会等回调跑完再重载页面。

规避方案 #

根据实际业务诉求选择对应方案即可：

• 如果process是单向触发类操作（比如操作日志上报、无状态通知类请求），不需要前端感知执行结果：不要把核心前端逻辑放在subscribe回调里，需要前端同步执行的逻辑直接放到请求发起前执行即可。
• 如果必须保证请求完成后的逻辑一定执行，不要把后续逻辑绑定在组件级的订阅上：
  • 若需要兼容用户主动刷新的场景：发起请求时先往sessionStorage写入带唯一标识的待处理任务标记，页面每次初始化时先检查存储中是否存在未完成的任务，主动查询对应请求的处理状态，补做后续的emit等逻辑。
  • 若只是为了避免用户误刷新打断流程：可以在存在未完成的请求订阅时，监听window.beforeunload事件弹出浏览器原生确认提示，告知用户当前有操作未完成，确认后再允许刷新。
• 注意所有组件内的订阅都要在组件销毁生命周期中主动取消，不要依赖页面刷新自动清理，避免正常路由切换时的内存泄漏。

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