主题切换方案最容易被做成“按钮一按，颜色一换”。这种做法在简单页面里看起来没问题，但一进入真实业务系统，就会暴露出很多细节：刷新时页面先亮后暗，弹窗和抽屉没有跟随主题，图表线条在深色背景下看不清，表单禁用态对比度不足，甚至某些第三方组件仍然停留在旧颜色里。

所以，主题切换不应该从“深色模式”开始设计，而应该从“颜色语义”和“状态来源”开始设计。页面里的按钮、卡片、表格、提示框不直接关心当前是浅色还是深色，它们只引用语义变量；至于这些变量最终对应什么颜色，由根节点上的主题状态统一决定。

一个可维护的主题系统至少要回答四个问题：颜色从哪里来，主题状态由谁决定，页面首次渲染时如何避免闪烁，哪些区域不能只靠普通样式变量覆盖。把这四个问题拆开之后，主题切换就不再是一个按钮事件，而是一条从初始化到运行时同步的完整链路。

变量分层的目标，是让业务组件不直接接触具体色值。最底层是基础色，只表达色阶；中间层是语义变量，表达“这个颜色用来做什么”；最上层是组件变量，处理某个组件在不同状态下的细节。如果跳过中间层，组件会很快和某一套视觉主题绑定死。

主题闪烁通常发生在这里：页面先按默认浅色渲染，脚本执行后才发现用户上次选择了深色，于是整页突然变暗。解决这个问题的关键，是在主要样式渲染前完成主题判断。服务端能直接输出主题状态最好；如果不能，也应该把很小的初始化脚本提前执行。

已保存主题 = 读取本地存储中的主题选择
系统偏好 = 读取系统颜色偏好
当前主题 = 已保存主题 或 系统偏好 或 默认浅色

把当前主题写入页面根节点
让后续样式根据根节点主题取值

用户在编辑表单、打开弹窗、展开下拉菜单时切换主题，页面不应该丢失这些交互状态。因此主题切换应尽量只改变根节点主题和样式变量，不重新挂载整棵页面。需要额外处理的区域，可以通过统一的主题变更通知来更新，而不是让每个业务组件各自监听和判断。

很多主题切换问题不是出在普通按钮和文本上，而是出在“看起来不像样式”的地方。例如图表色板、图片透明区域、代码块高亮、富文本编辑器、打印样式。这些边界如果上线前没有列入验收，后面通常会变成零散的视觉缺陷。

1. 一
   首次渲染没有闪烁 刷新页面时不会先出现错误主题，再切换到正确主题。
2. 二
   手动选择可以持久化 用户选择主题后，刷新、重新进入页面都保持一致。
3. 三
   浮层和弹窗能继承主题 抽屉、弹窗、菜单、提示框即使挂载在页面外层，也能拿到正确变量。
4. 四
   交互状态不被清空 切换主题时，表单输入、展开状态、当前路由、弹窗状态都保持不变。
5. 五
   深浅主题都通过可访问性检查 文本、禁用态、错误态、图表标注和边框都要分别检查对比度。