JavaScript 中需手动实现颜色亮度计算，核心是将 CSS 颜色统一转为 RGB 整数（0–255），再代入 WCAG 公式 (0.2126×R + 0.7152×G + 0.0722×B) / 255 得 0–1 结果。
怎么用 JavaScript 算出一个 CSS 颜色的亮度值
直接用 getLuminance 这类函数？没有。浏览器不提供现成 API，得自己算。核心是把颜色转成 RGB（或十六进制 → 十进制），再套用 WCAG 定义的相对亮度公式：(0.2126 * R + 0.7152 * G + 0.0722 * B) / 255，结果在 0～1 之间。
常见错误是直接拿十六进制字符串当数字用，比如把 "#fff" 当成 0xfff 算——漏补零、没转通道、忽略 alpha 通道都会让结果偏高。
- 十六进制要统一处理为 6 位：
"#f00"→"#ff0000"，否则parseInt("f0", 16)会错读红通道 - RGBA 颜色必须先转成 RGB：透明度不影响亮度计算，但 alpha 混合后实际显示亮度会变，这里只算“纯色本体”亮度
- HEX 字符串开头的
"#"必须去掉，否则parseInt("#ff0000", 16)返回NaN
RGB 转亮度时，为什么不能直接用 Math.max(r, g, b)
因为人眼对不同颜色敏感度差异很大：绿色最亮，红色次之，蓝色最暗。用最大值等同于假设三通道权重相等，会导致深绿（如 rgb(0,100,0)）算出来比深红（rgb(100,0,0)）亮近 7 倍，而实际感知亮度差没那么大。
WCAG 公式里的系数 0.2126、0.7152、0.0722 就是基于 CIE 标准观察者模型加权得出的，不是经验拍的。
立即学习“前端免费学习笔记（深入）”；
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 如果只是做简单明暗分类（比如“深色背景配浅字”），用最大值可能够用，但 WCAG 合规检测、自动主题切换这类场景必须用加权公式
- 注意 RGB 输入必须是 0～255 的整数，不是百分比或浮点；
rgb(80%, 0%, 0%)得先换算成rgb(204, 0, 0)
动态调整 CSS 颜色时，亮度值怎么反推新颜色
亮度本身不可逆——多个不同 RGB 组合可以算出同一个亮度值（比如 rgb(255,0,0) 和 rgb(0,0,255) 亮度分别是 ~0.21 和 ~0.07，但调亮度到 0.5 时，你得决定往哪条路径走：更红？更绿？还是保原色饱和度？）
所以「根据亮度调整颜色」本质是约束优化问题，不是数学反解。实践中分两类：
- 微调：保持色相和饱和度，只调明度（HSL 模式下改
l值），最安全。用hsl(120, 100%, 50%)→hsl(120, 100%, 70%)，亮度自然上升 - 重映射：已知目标亮度
L_target，从原色出发沿灰度轴插值，比如lerp(rgb(100,50,200), rgb(255,255,255), factor)，factor 通过试算逼近L_target - 别碰 HSV/HSL 的
V或L直接当亮度用——它们是表示法，不是感知亮度，hsl(0,0%,50%)是灰色，亮度确实是 0.5，但hsl(120,100%,50%)的亮度其实是 ~0.49，不严格等于 L 值
Chrome DevTools 里看到的 getComputedStyle(el).color 返回值怎么处理
返回的是浏览器解析后的标准格式，可能是 "rgb(255, 0, 0)"、"rgba(255, 0, 0, 0.5)"、"#ff0000"，甚至 "currentColor" 或 "inherit"。不能假设格式统一。
最容易踩的坑是正则提取数字时没覆盖所有情况，比如把 "rgb(10, 20, 30)" 里的 10 当成两位数，结果取成 102。
- 用
match(/(\d+\.?\d*)/g)提取所有数字，再取前三个（忽略 alpha）；但要注意小数，比如rgb(12.5, 30, 200) -
"currentColor"必须递归查父元素，getComputedStyle不会自动展开它 - 关键词如
"red"、"darkblue"需查 CSS 颜色关键字表转换，不能靠document.createElement临时测——有些老浏览器不支持全部关键字
亮度计算本身不难，难的是颜色输入来源五花八门，每种都要兜底；而且一旦涉及自动调色，就得明确目标：是适配可访问性？还是视觉协调？还是还原设计稿？目标不同，算法取舍就完全不同。
