浏览器不改写rgb()值，而是解析后归一化为标准格式并按设备色彩空间重解释；Computed面板显示rgb(255,0,0)是统一内部表示，非修改源码；色彩差异源于sRGB与display-p3等映射差异，非数值篡改。
浏览器不会“自动改写”你写的 rgb() 值，但会在解析后统一归一化为标准格式，且渲染时可能按设备色彩空间重新解释——这不是改写，而是确定性转换与底层映射。
Computed 面板显示 rgb(255, 0, 0) 不代表你写的被“修改”了
你在 Styles 面板里写 color: #f00; 或 color: red;，Computed 面板却显示 rgb(255, 0, 0)，这并非浏览器“改了你的代码”，而是它把所有颜色语法统一转成内部表示。这个过程是单向、无损、不可逆的：
-
#f00、#ff0000、rgb(255, 0, 0)、red四者在解析完成后，都变成同一个内部颜色对象 - Computed 面板只展示最终计算值，不保留原始写法；Styles 面板才显示你写的源码
- JavaScript 调用
getComputedStyle(el).color返回的永远是rgb()或rgba()字符串，不是你原始输入
rgb(255, 107, 107) 在 Safari 和 Chrome 里渲染不同，不是被“改写”，而是被“重解释”
同一段 rgb(255, 107, 107)，在 macOS Safari 中可能更粉，在 Windows Chrome 中偏橙——这不是浏览器篡改了数值，而是它们对“未声明色彩空间的颜色”采用了不同默认解释路径：
- Safari（尤其 macOS/iOS）默认将未声明空间的
rgb()和#RRGGBB映射到display-p3色域输出 - Chrome v110+ 和 Firefox 默认坚持 sRGB 解释，结果更保守、饱和度略低
- 这种差异发生在光栅化阶段，不在 CSS 解析时；你写的值没变，只是被喂给了不同的色彩空间转换器
别指望浏览器保留你的写法细节，尤其是缩写和命名色
你写 #abc，浏览器解析后内部存的是 rgb(170, 187, 204)；你写 steelblue，它查表转成 rgb(70, 130, 180)。这些转换不可逆，也不可配置：
立即学习“前端免费学习笔记（深入）”；
-
#abc不等于#a0b0c0，它是#aabbcc的简写，展开规则固定 - 预定义颜色名（如
tomato）仅 148 个，且部分在旧 WebView 中不支持，必须靠工具转成 HEX 或 RGB 降级 - 使用 CSS 变量（如
--primary: #ff6b6b;）时，getComputedStyle返回的仍是计算后的rgb()，原始变量名和写法信息彻底丢失
真正容易被忽略的点是：你看到的“改写”，往往其实是两件事混在一起——解析归一化（确定性、无害），和色彩空间映射（平台相关、不可控）。前者没法绕开，后者必须用 color(srgb ...) 显式约束，否则设计稿和线上效果差一截，你根本查不到哪行代码“动了颜色”。
