路由复用策略下，已分离组件接收订阅事件是否可行？

有利的场景 #

• 强状态连贯性需求：如果你做的是复杂表单、交互式数据看板这类用户需要长时间操作的组件，分离后保留订阅（比如同步后端实时更新的表单数据），能让用户切回路由时直接拿到最新状态，不用重新加载或同步，体验完全无缝。
• 轻量全局事件：如果订阅的是主题切换、用户登录状态变更这类低频率、低开销的全局事件，分离时继续接收完全没问题，反而能让组件重新挂载时直接适配最新全局状态，省去额外的初始化同步步骤。

要警惕的风险 #

• 性能浪费：要是订阅的是WebSocket高频推送、滚动/鼠标移动这类事件，分离后的组件虽然不在页面上，但逻辑还在跑，持续处理事件会占内存和CPU，复用多了很容易导致页面卡顿。
• 状态混乱：如果事件会修改组件状态，但用户看不到组件，等切回来发现状态变了，完全摸不着头脑，反而破坏交互预期。比如用户在编辑表单时切走，回来发现内容被后台事件改了，这就很糟。
• 内存泄漏：要是忘记在组件分离时解绑订阅，组件会被事件引用拽着没法被垃圾回收，日积月累内存占用越来越高，严重时会崩页面。

实操建议 #

• 按需管理订阅生命周期：在组件的分离钩子（比如Vue的deactivated、React里路由复用对应的卸载替代钩子）里，区分事件类型处理：高频、非必要的直接取消订阅，低频全局事件可以保留。
• 加分离状态标记：如果必须留订阅，给组件加个isDetached变量，事件回调里先判断状态，只处理对后续激活有用的逻辑，跳过DOM相关操作（反正组件不在页面上，白忙活）。
• 做两类测试：一是长时间停留在其他路由，看内存和CPU占用；二是模拟事件触发，检查切回路由后组件状态是否符合预期，有没有乱改的情况。

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