RGBA仅当原色为可简写的6位色值（如#FF00FF→#F0F）时合法，A位按AA扩展换算透明度，实际不透明度为AA/255，非线性对应；它仅省2字符却易引发精度与兼容性问题。
什么时候能用 #RGBA 这种4位写法
只有原色本身是「可简写的6位色值」时，#RGBA 才合法。也就是说，#RRGGBB 中每两位必须相同：比如 #FF00FF → 可缩为 #F0F，那它的8位透明变体 #FF00FF80 才能缩成 #F0F8。
常见能缩写的颜色就那么几个：#000、#fff、#f00、#0f0、#00f、#ff0、#0ff、#f0f。其他像 #ff5733 或 #2c3e50 都不行——强行写成 #f533 会被浏览器解析为 #ff5533，颜色完全跑偏。
-
#fff8等价于#ffffff88（≈85% 不透明，不是 50%） -
#0000是全透明黑，#000f是接近不透明的黑（#000000ff） - 别拿
#f533去套#ff573380—— 它实际对应的是#ff5533，红通道从57错成了55
#RGBA 的透明度位（A）怎么换算
#RGBA 中的 A 是单个十六进制数字（0–F），它会被浏览器自动扩展成两位：A → AA。所以 #f0f8 实际是 #ff00ff88，其中 88 十进制是 136，136 ÷ 255 ≈ 0.533，也就是约 53% 不透明（47% 透明度）。
-
0→00→ 全透明 -
8→88→ ≈53% 不透明（不是 50%） -
c→cc→ 204 ÷ 255 ≈ 0.8（80% 不透明） -
f→ff→ 完全不透明
想精确控制 50% 透明度？别用 #RGBA，老实用 #RRGGBB80 或 rgba()。
立即学习“前端免费学习笔记（深入）”；
为什么 #RGBA 在开发者工具里显示为 rgb()？
Chrome、Firefox 等现代浏览器解析 #RGBA 后，会统一转成 RGB(A) 格式存入计算样式（getComputedStyle 返回的也是 rgb() 或 rgba()）。这不是 bug，是规范行为。你写 background: #00f8，控制台看到 rgba(0, 0, 255, 0.502) 是正常的——因为 8 → 88 → 136/255 ≈ 0.502。
- 别靠肉眼判断是否生效：检查 computed styles，看 alpha 值是不是你预期的
- 如果看到
rgb(0, 0, 255)（没 alpha），说明浏览器根本不认识这个写法（比如旧 Safari 或 IE），降级失败了 - VS Code 插件如 “Color Highlight” 通常不支持高亮
#RGBA，得手动确认语法是否被识别
该不该在项目里用 #RGBA 缩写
能用，但要清楚代价：它只省 2 个字符，却牺牲了精度和可读性。团队里有人把 #f0f8 当成 50% 透明，结果发现背景比设计稿深，这种隐性误差很难排查。
- 适合快速原型、内部工具、已知运行环境全是 Chrome/Firefox/Edge 90+ 的场景
- 不适合对外交付、需要兼容 Safari ≤12、或设计师给的透明度要求严格到 ±2% 的项目
- 更稳妥的做法：用
#RRGGBBAA全写（如#00000080），既明确又无歧义，多数编辑器也能实时预览
真正容易被忽略的点是：4位写法不是“更高级”，只是“更省事”，而省事的前提是你已经把透明度梯度、浏览器支持、团队认知全都对齐了。
