系统外观颜色不可靠，因其由操作系统和浏览器联合解释，导致跨平台表现差异大、不支持CSS变量管理、高对比度模式下易失效，且构建工具可能静默丢弃；应改用语义化自定义属性（如--text-ui）配合媒体查询实现可控配色。
系统外观颜色（如 buttonface、canvastext）在 CSS3 中并未被“废弃”，但现代项目中确实应主动避免依赖它们——因为它们不可控、不可预测，且与语义化配色目标根本冲突。
系统外观颜色为什么在实际项目中不可靠
这些关键字由操作系统和浏览器联合解释，同一值在不同环境表现差异极大：
-
buttonface在 Windows 10 深色模式下可能是灰蓝，在 macOS Monterey 下是浅灰，在 Linux GNOME 下可能直接 fallback 到白色 -
canvastext在高对比度模式下会被强制映射为系统定义的“文本色”，但若页面用了!important或内联样式，它就失效，导致文字彻底不可读 - 它们不参与 CSS 自定义属性体系，无法被
var(--text-primary)统一管理，也无法做深色模式条件重定义 - 构建工具（如 PostCSS、Lightning CSS）会把未知颜色关键字当作无效声明丢弃，造成静默失败
语义化配色如何替代系统外观色
真正可维护的方案不是“换一个颜色名”，而是重构颜色的归属逻辑：
- 用
--text-ui替代canvastext，用--bg-control替代buttonface，让变量名回答“这个颜色承担什么 UI 角色” - 在
:root中定义基础层变量，并在@media (prefers-color-scheme: dark)和@media (forced-colors: active)中分别覆盖值 - 关键边界要守住：比如
--text-ui只用于文字前景，绝不用于background-color—— 否则 WCAG 对比度校验会失败 - 如果必须保留系统语义（如按钮默认态），可用
color: CanvasText; forced-color-adjust: none;，但仅限装饰性图标等极少数场景
currentColor 不等于系统外观色，但常被误用
currentColor 是继承自元素自身 color 值的动态别名，不是系统色。它的危险在于“透明度透传”：
立即学习“前端免费学习笔记（深入）”；
- 若
.label { color: rgba(0, 0, 0, 0.6); }，那么border-color: currentColor;也会带 0.6 透明度，边框可能低于 WCAG AA 级对比度 - 旧版 Safari（≤15.6）对
currentColor在fill或border中的 alpha 处理不一致，有时会渲染为全不透明 - 它无法响应
forced-colors模式切换——系统接管的是color属性本身，而currentColor只是它的镜像，不会被重映射
语义化配色最难的不是命名，而是拒绝“看起来差不多就行”的惯性。系统外观色就像全局变量，初看省事，越往后越难定位问题。真正稳定的体系，靠的是显式约定，而不是隐式依赖。
