filter不改变CSS颜色值本身，仅对渲染后的像素做后处理，getComputedStyle获取的仍是原始颜色值，其变换是纯像素级数学运算，与颜色语义完全解耦。
filter 作用于渲染后的像素，不改变 CSS 颜色值本身
不会。filter 是在浏览器完成布局、绘制（paint）之后，对已生成的像素块做后处理（post-processing），它不介入颜色计算、不修改 color、background-color 等属性的原始值，也不影响 CSSOM 或 computed style 中的颜色表示（如 rgb(255, 0, 0) 仍返回原值）。你用 getComputedStyle(el).color 拿到的还是未滤镜前的值。
filter 的颜色变换是纯像素级的仿射/非线性映射
所有 filter 函数（如 grayscale()、sepia()、invert()、contrast()、hue-rotate()）本质上是对每个像素的 RGBA 四通道做数学变换，底层接近 WebGL 片元着色器行为：
-
hue-rotate(90deg)不是“把 color 值从 hsl(0, 100%, 50%) 改成 hsl(90, 100%, 50%)”，而是对每个像素的 RGB 值乘以一个旋转矩阵，再 clamp 到 [0, 255] -
invert(1)等价于rgba(r, g, b, a) → rgba(255−r, 255−g, 255−b, a)，不关心原始颜色模型（hex / rgb / hsl / oklch） -
contrast(0)会把所有非透明像素压成灰阶中值（≈128），但该结果不可逆，也无对应 CSS 颜色值可表达
实际开发中容易踩的坑
因为 filter 是后处理，它和颜色语义完全解耦，这带来几个典型问题：
- 无障碍（a11y）失效：屏幕阅读器或高对比度模式无法感知
filter: invert()后的真实视觉颜色，可能导致文字不可读但检测不到对比度不足 - 截图 / canvas 导出失真：调用
canvas.getContext('2d').drawImage()捕获带 filter 的元素时，若未启用will-change: filter或硬件加速，可能截到未应用 filter 的帧 - 与
opacity叠加顺序敏感：filter 作用在 opacity 合成之后（即先 opacity 混合，再 filter），所以opacity: 0.5; filter: blur(2px)的模糊是半透明内容模糊，而非全不透明内容模糊后再降透明度 - 性能隐性开销：
filter: blur(4px)或filter: url(#svg-filter)会强制图层提升（layer promotion），触发额外的 GPU 纹理上传和离屏渲染，滚动时易掉帧
/* 示例：同一颜色，filter 前后 computed style 不变 */
.element {
color: #ff0000;
filter: hue-rotate(180deg) brightness(1.2);
}
/* getComputedStyle(el).color === "rgb(255, 0, 0)" —— 依然返回原始值 */需要颜色语义时，别依赖 filter
如果你要动态控制主题色、做颜色对
filter “看起来像变了”。filter 是视觉糖，不是颜色系统的一部分。它甚至不能表达 sRGB 和 display-p3 色域切换这种底层变化——那些必须由 color-scheme、color-gamut 媒体查询或 color() 函数承担。
