我在调整一个 React 桌面界面的主题插件时，遇到过一个很容易误判的问题：主界面里的精简效果正常，打开设置页后却消失；退出设置，效果又回来了。看起来像设置页覆盖了样式，实际排查后，问题不在颜色、选择器或优先级，而在一个更基础的决定：本来要随插件持续生效的行为，被放进了一个会临时卸载的菜单组件里。
这不是某个应用独有的技巧。只要一个扩展同时包含临时界面和长期行为，就值得先问：谁应该负责安装它，谁有权停止它？
先把“看不见”与“被清理”分开
当时我需要让主题选择界面只呈现常用选项，同时保留原有主题数据与切换逻辑。插件里恰好有一个菜单组件，把呈现逻辑放在那里很顺手：菜单挂载时安装，菜单卸载时清理。
初次进入主界面，这套安排工作正常。问题出现在打开设置时：主界面的菜单会被卸载，但插件并没有被禁用，设置里的主题选择界面反而正需要这项呈现逻辑。菜单的清理函数提前结束了它。
因此，我没有先继续加 CSS，而是按事件顺序检查三件事：
- 打开设置时，承载逻辑的菜单是否还挂载着？
- 效果消失之前，清理函数是否已经执行？
- 返回主界面后，是否因为菜单重新挂载，效果才恢复？
在这个案例里，答案指向同一条因果链：页面切换卸载菜单 → 清理逻辑执行 → 插件效果消失；返回页面重新挂载 → 重新安装 → 效果恢复。
这个顺序比“某一刻样式有没有命中”更有解释力。
空依赖数组，不等于应用生命周期
React 官方文档明确说明：组件从 DOM 中移除后，React 会执行 Effect 的清理函数。1 因此，下面这种写法并不能表示“只要插件启用就一直存在”：
function Menu() {
useEffect(() => {
const dispose = installPresentation();
return dispose;
}, []);
return <MenuContent />;
}
这里的函数名只是说明结构的示意，不是可直接粘贴到任意插件中的 API。真正决定寿命的，仍然是 Menu 这个组件。菜单消失时，dispose 被调用，是合理的 React 行为；错误的是我把另一种寿命的需求交给了它。
还要区分两件事：组件是否挂载，以及 Effect 是否需要重新同步。React 官方将 Effect 描述为开始同步、停止同步的独立过程；依赖变化也可能引起清理与重新设置，不能把每次 cleanup 都解释成组件被卸载。12
对这个案例而言，我需要核实的是实际卸载路径，而不是仅凭一条清理日志下结论。
修正归属，而不是取消清理
我的修正是把职责拆开：菜单负责显示当前选择、发起切换，并提供最新的界面元数据；长期呈现逻辑由插件的存续范围持有。打开设置、卸载菜单，不再停止这项逻辑；真正禁用插件时，才统一撤销观察、事件监听和临时样式。
可以把结构概括为：
// 示意：实际注册、销毁接口取决于插件平台。
function activatePlugin(lifecycle) {
const disposePresentation = installPresentation();
lifecycle.onDispose(disposePresentation);
lifecycle.registerMenu(Menu);
}
这里的关键不是某个注册函数，而是安装者与释放者属于同一个正确的生命周期。
我也没有选择“干脆不清理”。那样可以暂时掩盖设置页的问题，却让禁用插件后仍残留的行为变成另一个缺陷。正确结果必须同时满足：临时组件离开时不误删长期行为，插件真正退出时不留残余。
另一个容易漏掉的问题是数据新鲜度。把逻辑移到更长寿命的范围，并不意味着第一次读取的主题清单可以永久使用。在这项实现中，目录由菜单挂载时更新，启动和菜单卸载期间可能使用缓存；匹配未知或重复时保留原界面。这减少误隐藏风险，但不保证目录始终实时同步。需要实时跟随目录变化的插件，还应接入平台提供的可靠订阅，而不是把长寿命误当成新鲜度保证。
我怎样验证这不是一次“碰巧好了”
原来的工程记录已有插件生命周期绑定与清理检查。为了把文章里的机制说清楚，我又在隔离的 React/jsdom 环境做了一个最小复现，使用的 react-dom 版本为 19.2.7。这个复现不操作日常客户端，也不代表该版本是当前最新版。
测试把“安装呈现逻辑”缩减为一个可断言的开关，分别运行错误结构与修正结构：
- 菜单持有逻辑时，打开设置会卸载菜单，开关关闭；返回后重新开启。
- 改为插件范围持有后，打开设置、返回、再次打开，开关一直保持开启，没有重复安装。
- 显式销毁插件范围后，开关关闭，清理与安装配对。
这些断言实际通过了。它证明的是生命周期因果与释放边界，不是完整视觉验收：jsdom 不能替代真实浏览器的渲染检查。实际交付仍应检查设置打开、返回、禁用、重新启用，以及键盘操作和原生选项是否正常。
我现在更重视这种“先让旧结构稳定失败，再让新结构通过”的对照。只看到修正后的界面正常，很难排除是刷新、重新挂载或残留状态暂时帮了忙。
适用边界：不是所有逻辑都该搬到全局
如果监听、动画或资源只服务一个组件，那么随组件卸载而清理正是正确安排。只有当行为需要跨页面、跨临时菜单持续生效时，才应寻找更长寿命、且能明确释放的持有者。
如果打开设置只是遮住原界面，没有卸载组件，这篇文章的因果链也不成立。下一步应检查依赖变化、目标节点被替换、选择器失配或样式覆盖，而不是照搬“移到插件范围”的修法。
这次排障给我的结论很简单：效果消失时，不要只问“哪条样式失效了”，也要问“负责维持效果的那段逻辑，还活着吗”。 很多看似视觉层的偶发问题，真正需要修正的不是样式，而是行为的生命周期归属。
本文由真实排障记录与隔离复现整理，AI 辅助编辑；应用身份及内部配置已省略。官方资料核验于 2026 年 10 月 2 日，下列文档未标注独立发布日期。
一手来源与适用边界
- React 官方：useEffect。用于核对组件卸载后的清理行为，以及依赖变化引起的清理和重新设置。
- React 官方：Effect 的生命周期。用于区分组件生命周期与同步过程。文档核验于 2026 年 10 月 2 日，未标注独立发布日期。
