Chrome和Firefox禁用大部分系统颜色是为防止隐私泄露，仅Canvas、CanvasText、Field、FieldText等少数关键字仍安全可用，现代替代方案是@media(prefers-color-scheme)配合CSS变量与color-scheme声明。
系统颜色关键字被限制的直接原因
Chrome 和 Firefox 从 2023 年起逐步禁用大部分传统系统颜色（如 ButtonFace、Highlight、Scrollbar），不是因为它们“不能用”，而是浏览器主动将其设为无效值——解析时静默降为 initial 或 can't resolve。根本动机是防止网站通过读取这些颜色值反推用户操作系统、主题模式甚至隐私设置（比如深色模式开启状态可暴露用户作息习惯）。Safari 仍保留较完整支持，但仅限 macOS 原生渲染路径；Edge 因基于 Chromium，行为与 Chrome 一致。
哪些系统颜色还能安全使用
W3C 明确保留了少数几个具备语义且无隐私风险的颜色关键字，目前可在所有主流浏览器中稳定生效：
-
Canvas、CanvasText、ButtonFace（仅 Safari/macOS）、Field、FieldText -
GrayText（表示禁用文本，非系统灰度值） -
transparent、currentcolor、inherit—— 这些不属于“系统色”，但常被误归类，实际是通用关键字，完全可用
注意：ActiveBorder、AppWorkspace、Background 等在 Chrome/Firefox 中已彻底失效，写上去不会报错，但计算值恒为 rgb(0, 0, 0) 或透明，不可依赖。
@media (prefers-color-scheme) + color-scheme 是现代替代核心
系统颜色本意是让网页自动适配 OS 主题，现在这个目标由更可控、更标准的方式实现：
立即学习“前端免费学习笔记（深入）”；
- 用
@media (prefers-color-scheme: dark)切换整套 CSS 变量，例如：--bg: #ffffff; --bg-dark: #1a1a1a; - 在根元素声明
color-scheme: light dark;，告知浏览器你支持哪些配色方案，触发原生表单控件（<input>、<select>）自动切换 - 避免混合使用：不要在
@media块里再写background-color: ButtonFace;，它可能已被忽略，导致 fallback 失效
这种组合不依赖系统色值本身，而是靠开发者明确定义语义化变量，既保有主题响应能力，又杜绝隐私泄露路径。
为什么不用 color-mod() 或旧 PostCSS 插件做兼容
color-mod() 函数早在 CSS Color Module Level 4 草案阶段就被移除，没有浏览器原生支持。所有看似“可用”的案例，都是构建时经 postcss-color-mod-function 编译成固定 RGB 值的结果：
- 编译后失去响应性：
color-mod(var(--bg) lightness(-20%))→rgb(200, 200, 200)，改变量不会更新 - 无法嵌套或参与
color-mix()计算，和现代色彩函数不互通 - PostCSS 插件在 Vite/Webpack 5+ 中默认不启用，需手动配置，CI 环境易漏装
真正需要动态调色的场景，应直接用 color-mix(in oklch, ...) 或 lch()，它们是运行时解析、支持 CSS 变量、且通过 @supports 可检测的合法语法。
最容易被忽略的一点：系统颜色失效不是“bug”，而是浏览器有意为之的隐私防护机制。试图绕过它（比如用 JS 读取 computedStyle 再 fallback）不仅徒劳，还可能触发额外的 CSP 报警或被标记为可疑行为。接受变量驱动的主题模型，才是当前最稳定、最可维护的路径。
