color()函数本质是显式声明颜色来源的色彩空间，用于浏览器语义化解析与设备适配，必须配合srgb、display-p3等完整空间名使用，不支持缩写或fallback语法，且当前仅Safari在特定条件下支持。
color() 函数不是“让颜色更鲜艳”的快捷键，它本质是**显式声明颜色的来源色彩空间**，浏览器据此做语义化解析和设备适配。不带空间标记的 rgb() 或 #ff0000 默认按 sRGB 处理，无法反推原始空间；而 color(display-p3 1 0 0) 明确告诉浏览器：“这是 Display P3 色域下的纯红”，后续才可能做感知一致的映射或降级。
color() 必须配合具体色彩空间名使用
语法是 color(<color-space> <p1> <p2> <p3> / <alpha>)，<color-space> 不可省略，也不能拼错。目前稳定可用的包括：srgb、display-p3、rec2020、prophoto-rgb、a98-rgb。写成 color(rgb 1 0 0) 或 color(p3 1 0 0) 会直接被忽略——CSS 解析器不识别缩写或别名。
-
color(srgb 1 0 0)和rgb(255 0 0)在语义上等价，但前者强调线性光值（无 gamma 压缩），后者是 legacy 表示 -
color(display-p3 1 0 0)只在 Safari for iOS/macOS 真机 + HTTPS + P3 屏幕 + 广色域开启时可能生效；Chrome/Firefox 当前完全忽略该声明，回退为黑色或继承色 - 渐变中用
color(display-p3 0 0 1)作 stop 颜色？不行——linear-gradient()的 color stop **不支持**color()函数，会静默失败
不能把 color() 当作 fallback 容器来写
很多人误写 color: color(display-p3 1 0 0) red;，以为这是“P3 红，不行就用 sRGB 红”。实际结果是：整个声明被丢弃，元素用默认 color（通常是 inherit 或初始 black）。CSS 不支持这种 fallback 语法，color() 后面跟其他值属于无效声明。
- 真正跨浏览器安全的做法是层叠：先写通用 fallback，再覆盖
color()，例如color: red; color: color(display-p3 1 0 0); - 注意顺序：后声明的生效，所以
color()必须放在静态色值之后 - 不要加
!important强行提权——它不能修复语法错误，只会掩盖问题
color() 本身不转换颜色，只提供上下文
color() 不像 color-mix() 那样计算新值，它只是给浏览器一个“这是哪来的”提示。是否转换、怎么转换，取决于浏览器实现、系统设置和输出设备能力。例如：
立即学习“前端免费学习笔记（深入）”；
- 你在 macOS 上用
color(rec2020 0.2 0.8 0.4)，但显示器只支持 sRGB，浏览器会按规范做色域映射（通常用相对色度法），但结果未必是你在 Rec.2020 监视器上看到的原样 -
color(srgb 0.2 0.8 0.4)≠rgb(51 204 102)：前者是线性光值，后者是 gamma-compressed，现代渲染引擎会区分处理 - 想把 P3 颜色“转成”sRGB 可显示值？不能靠
color()单独完成，得结合color-mix()做感知相似降级，比如用color-mix(in srgb, red 90%, white 10%)模拟高饱和红的视觉重量
真正容易被忽略的是：color() 的价值不在“显示更广色域”，而在**统一描述源头**。当你从设计工具导出一组 Display P3 色值，或对接视频/印刷工作流时，保留空间元信息才能避免后期不可控的隐式转换。但日常 UI 开发中，它目前仍是 Safari 专属的窄路径，别指望靠它解决配色一致性问题——color-mix() + oklch() 才是更现实的动态基础。
