8位HEX（#RRGGBBAA）虽标准但兼容性差，Chrome65+/Firefox49+/Safari17.4+支持，Electron、微信WebView等会退化为不透明；必须双写rgba() fallback，如background-color: rgba(255,107,107,0.3); background-color: #ff6b6b4d。
8位HEX写法本身没问题，但浏览器支持不统一
Chrome 65+、Firefox 49+、Safari 17.4+ 原生支持 #RRGGBBAA，比如 #ff6b6b4d 表示 #ff6b6b 加约30%透明度（0x4d ≈ 77/255 ≈ 0.3）。但 Electron、微信 WebView、旧版 Android Browser、IE 完全不识别，会直接忽略后两位，退化为不透明的 #ff6b6b。
这意味着：如果你项目要兼容微信内嵌页或企业微信客户端，#RRGGBBAA 就不是“能用”，而是“会出错”。
常见错误现象：
— 开发时看着正常，上线后用户反馈背景突然变实心
— PostCSS 插件（如 autoprefixer）默认不处理 8 位 HEX，压缩时可能被误删或报错
— Figma/Sketch 导出颜色不带 alpha，手动补两位容易漏、补错位置（比如把 #0b79 错写成 #0b7900 而非 #00bb7700）
必须加 rgba() fallback 才算稳妥
现代写法必须双写，且 rgba() 放在前面：
立即学习“前端免费学习笔记（深入）”；
button {
background-color: rgba(255, 107, 107, 0.3);
background-color: #ff6b6b4d;
}原因：CSS 层叠规则下，浏览器按顺序解析，不支持 8 位 HEX 的会跳过第二行，沿用第一行；支持的则用第二行（更简洁、更易维护）。
注意点：
— rgba() 第四个参数必须是 0–1 小数，不能写 30% 或 30
— 不要用 Sass/Less 的 transparentize() 替代——它生成的是静态 CSS，无法响应 JS 动态改变量
— 如果原始色是 CSS 变量（如 --primary: #ff6b6b），别试图用 JS 拿值再转，容易因空格、大小写、简写（#f00）导致 parseInt 返回 NaN
4位HEX（#RGBA）只适用于特殊场景
#RGBA 是 #RRGGBBAA 的简写形式，要求 R=G=B=A 各通道数值相同，例如 #0b79 等价于 #00bb7799。但它有硬性限制：
- 不能用于任意颜色：比如
#ff6b6b无法简写成 4 位，因为f、6、b不相等 - 大小写敏感：浏览器把
#0B79当作非法值，部分解析器直接丢弃整条声明 - 设计系统里几乎没人用——Figma 不导出、设计师不标注、代码审查难发现
所以除非你明确控制所有输入色值且全是“各通道一致”的情况（比如主题色限定为 #112233 这类），否则别主动选 #RGBA。
真正该关注的，是透明度换算是否准确
30% 透明度 ≠ alpha = 0.3，这个说法本身就有歧义。设计系统里说的“30% 透明度”，通常指“保留 30% 不透明度”还是“允许 30% 光线穿透”？实际中两种理解都存在。
换算时务必确认基准：
— 若指“30% 不透明度”，对应 alpha = 0.3，十六进制 AA = Math.round(255 * 0.3) = 77 → #ff6b6b77
— 若指“70% 透明度”（即只剩 30% 不透明），则 alpha = 0.3 仍是正确值，但语义上容易和设计师对不上
最容易被忽略的一点：alpha 值在 CSS 渲染中是非线性的，尤其在 gamma 校正后的显示设备上。肉眼觉得“差不多”的两个 alpha 值，数值差可能达 0.05 以上。真正在意视觉一致性时，别信计算，要靠设计稿叠加预览校准。
