HEX透明度的AA两位本质是0–255整数，对应Alpha通道原始字节值：0x00=完全透明，0xFF=完全不透明；rgba()中alpha必须为0–1小数，需除以255换算，且须clamp、补零、厘清“透明度”指透出程度还是不透明度。
HEX透明度的AA两位本质是0–255整数
因为#RRGGBBAA里的AA不是百分比，也不是小数，而是直接对应Alpha通道的原始字节值：0x00 = 0（完全透明），0xFF = 255（完全不透明）。浏览器底层渲染时，图形API（如Skia、Core Graphics）接收的就是这个0–255范围的整型alpha。所以你看到#3a86ff7f，其中7f被解析为十进制127，就是“127/255 ≈ 0.498”的不透明度——不是0.5，但足够接近。
rgba()要求0–1小数，所以必须除以255
rgba()函数第四个参数的规范定义就是归一化浮点数，取值严格限制在0到1之间。它和HEX的AA属于不同抽象层级：AA是存储格式，rgba()是计算接口。不除以255就硬塞进去，比如rgba(58, 134, 255, 127)或rgba(58, 134, 255, 7f)，整条声明会被浏览器静默丢弃。
- 错误写法：
rgba(58, 134, 255, 50%)、rgba(58, 134, 255, 50)、rgba(58, 134, 255, 0x7f) - 正确换算：
Math.round(0.3 * 255) → 77 → "4d"，或parseInt("4d", 16) / 255 → 0.302
为什么不是除以256？
因为Alpha是**无符号8位整数**，取值是0到255共256个离散值，但最大值是255，不是256。就像数组索引从0开始，长度为256的数组最大下标是255。用256做分母会导致FF / 256 = 0.996，语义上违背“完全不透明”应为1.0的直觉。所有主流图形API（OpenGL、DirectX、WebGL）都按255归一化，CSS引擎也沿用这一约定。
工具链里最容易忽略的边界点
手写转换逻辑时，这三个地方一漏就翻车：
立即学习“前端免费学习笔记（深入）”；
- 没对输入
alpha做clamp：传入-0.1或1.5，Math.round(-0.1 * 255)得-26，转成十六进制是负数，toString(16)输出"-1a"，根本没法用 - 没补零：
(77).toString(16)是"4d"没问题，但(10).toString(16)是"a"，必须.padStart(2, "0")变成"0a" - 把“30%透明度”误解为“70%不透明度”：设计师说“加30%透明度”，意思是让颜色透出背景30%，即保留70%不透明度 → 应用
0.7 * 255 = 178.5 → 179 → "b3"，不是0.3 * 255
真正麻烦的从来不是公式本身，而是每次都要确认：这里说的“透明度”，到底指透出程度，还是遮盖能力。
