canvas颜色与css不匹配的本质是读取、赋值、渲染三环节未对齐：需用getcomputedstyle获取计算值并.trim()，仅支持w3c标准色名/十六进制/rgb()字符串，且受dpr、srgb色域、缩放影响。
Canvas 画布颜色与 CSS 颜色不匹配，本质不是“颜色错了”，而是你读到的、用到的、渲染的三个环节没对齐——getComputedStyle 拿的是 CSS 值，ctx.fillStyle 接受的是 Canvas 兼容格式，而浏览器最终显示还受设备像素比、sRGB 色域、透明度叠加影响。
如何安全读取 CSS 变量颜色值
直接用 getComputedStyle(root).getPropertyValue('--accent') 得到的字符串可能带空格、单位或 alpha 写法（如 rgba(59, 130, 246, 0.8)），Canvas 不认这些格式，会静默 fallback 到黑色。
- 必须
.trim()去首尾空格，否则' #3b82f6 '会被 Canvas 忽略 - 避免在
requestAnimationFrame或高频绘制循环里反复调用getComputedStyle，它会触发强制同步布局，卡顿明显 - 推荐在主题切换或初始化时缓存一次：比如
const accentColor = getComputedStyle(document.documentElement).getPropertyValue('--accent').trim() || '#3b82f6'，后续直接用变量 - 如果变量是
rgba()或hsl()，Canvas 2D 上下文原生支持，但务必确保字符串格式合法；若不确定，用color库或手动 fallback 到 hex
为什么 Canvas 绘制后颜色看起来“发灰”或“偏暗”
这不是 Canvas 的 bug，而是 sRGB 色彩空间与设计稿/屏幕输出不一致导致的。尤其在 macOS Display P3 屏、Windows HDR 模式下，同一 #4A90E2 渲染结果肉眼可辨差异。
- CSS 中写
color: #4A90E2，浏览器按 sRGB 解释；但设计稿若导出自 Figma 的 P3 色域，数值相同，色域不同 → ΔE > 6 - Canvas 的
fillStyle不做色彩管理，它忠实地把输入值映射到当前上下文的 sRGB 输出通道 - 用开发者工具「Computed」面板确认最终生效色值，别只看「Styles」里写的那行 ——
filter: brightness(0.9)或backdrop-filter: blur(2px)都会改变视觉效果 - 文字颜色在深色背景上被自动提亮（如 Chrome 对
color-scheme: dark的补偿）也会影响 Canvas 内文字渲染一致性
Canvas 尺寸缩放导致颜色“糊”或“错位”的连带影响
当 canvas.width/canvas.height 和 canvas.style.width/canvas.style.height 不一致时，Canvas 会拉伸渲染缓冲区——这不仅让图形模糊，还会让抗锯齿算法混入额外像素，间接改变边缘颜色感知。
- 例如：CSS 设为
width: 450px; height: 300px，但 canvas 元素自身width=300、height=150→ 所有绘制坐标被 x1.5 / x2 拉伸，fillRect(0,0,100,100)实际覆盖 150×200 像素区域，边缘采样变宽，颜色“泛开” - Flex 容器中
display: none时，getBoundingClientRect()返回 0，但getComputedStyle仍能读颜色 —— 此时尺寸逻辑和颜色逻辑要分开处理，不能共用同一判断分支 - 高 DPR 设备（如 DPR=2）下，仅靠 CSS 缩放无法提升清晰度；需用
canvas.width = Math.floor(clientWidth * window.devicePixelRatio)主动适配，并重设ctx.scale
最常被忽略的一点：CSS 自定义属性本身不参与色彩空间转换，--primary: #4A90E2 是纯字符串，但一旦它被用于 background、border 和 ctx.fillStyle 三处，而三者渲染路径不同（CSS 引擎 vs Canvas 2D 上下文 vs 硬件合成器），微小差异就会被放大。不要假设“写一样就显示一样”，要测、要查 Computed、要在真机上比对。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
