直接在 :root 定义 --primary-color 不生效是因为变量必须通过 var(--primary-color) 显式调用才能生效，CSS 不会自动注入到原生属性中；需手动在每个使用处写 color: var(--primary-color);。
为什么直接在 :root 里定义 --primary-color 不生效？
常见现象是：CSS 里写了 :root { --primary-color: #3498db; }，但页面元素没变色。根本原因不是语法错，而是变量没被消费——var(--primary-color) 必须显式写在要用它的属性值里，CSS 不会自动把变量“注入”到 color 或 background 这类原生属性中。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 每个用到主题色的地方，都得手动写
color: var(--primary-color);，不能只靠:root定义就完事 -
:root是作用域起点，但变量传播靠var()显式调用，它不继承、不隐式覆盖 - 如果组件用了 CSS-in-JS 或 Shadow DOM，
:root的变量默认进不去，得额外透传或用inherit触发继承链
移动端一键切换主题时，document.documentElement.style.setProperty 怎么用才不卡顿？
直接循环改十多个 --xxx 变量，再触发重排，容易造成点击后视觉延迟。关键在批量更新和避免强制同步布局。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把所有主题变量打包成一个对象，用一次
Object.entries(theme).forEach(([k, v]) => el.style.setProperty(k, v))更新，比多次setProperty更快 - 切换前加
document.documentElement.classList.add('theme-updating')，配合 CSS* { will-change: var(--bg); }提前提示渲染引擎 - 别在
click回调里读取offsetHeight或getComputedStyle，这会强制同步计算，打断批量更新流
prefers-color-scheme 与手动切换冲突怎么办？
用户开了系统深色模式，又点按钮切回浅色，结果下次刷新又跳回深色——因为 @media (prefers-color-scheme: dark) 的 :root 规则优先级高于 JS 设置的内联样式，除非你主动覆盖。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 放弃纯依赖媒体查询自动适配，改用 JS 检测
window.matchMedia('(prefers-color-scheme: dark)').matches后，把结果存进 localStorage，作为初始主题依据 - 所有主题相关
:root媒体查询规则删掉，只保留 JS 动态设置的内联样式，确保控制权在 JS 手里 - 监听
matchMedia变化，但仅当用户未手动切换过主题时才响应，用一个isManuallySet标志位区分
Android WebView 和 iOS Safari 对 var() 的兼容性差异在哪？
大部分现代 WebView 都支持，但老版本（如 Android 6–7 的 WebView、iOS 12.5 以下）对嵌套 var() 或 fallback 写法解析不稳定，比如 var(--color, var(--fallback)) 可能直接失效变成 transparent。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- fallback 值必须是字面量，别嵌套
var()，写成var(--color, #000)而非var(--color, var(--fallback)) - Android 7.0+ WebView 默认开启 CSS Custom Properties，但需确认是否启用
WebView.setWebContentsDebuggingEnabled(true)（仅调试），生产环境不用管 - iOS Safari 从 9.3 开始支持，但早期版本对 :root 中带 calc() 的变量计算有 bug，例如
--gap: calc(1rem + var(--spacing));在 iOS 11.2 会算错，拆成两步定义更稳
主题切换看着只是改几个颜色，实际要同时扛住 JS 执行时机、CSS 作用域、客户端解析差异三重压力。最常漏掉的是：没清空旧主题 class，或 fallback 值写成变量导致降级失败。
