css filter 的 blur() 必须带单位（如 blur(2px)），无单位值无效；filter 按书写顺序执行，不可逆；fixed 元素使用 filter 易致性能下降和渲染异常；动画慎用 transition，优先静态控制或分段切换。
filter 模糊值写成 blur(2) 会失效
CSS 的 filter: blur() 必须带单位，写成 blur(2) 浏览器直接忽略，实际生效的是 blur(2px) 或 blur(0.5em)。这个错误在快速复制粘贴时特别常见——很多人从 JS 动态拼字符串或从设计稿数值里直接抄数字，忘了补单位。
常见错误现象：filter: blur(3) 看不出模糊效果，DevTools 里该声明被划掉（invalid value）；filter: blur(0) 倒是合法，但别指望它“重置”其他 filter 效果——它只控制模糊，不影响灰度或饱和度。
-
blur()只接受长度值（px、rem、em），不接受无单位数字或百分比 - 超过
100px后性能明显下降，尤其在移动端，建议控制在0–20px范围内 - 和
transform: scale()同时使用时，模糊会作用于缩放后的像素，可能意外加重失真
灰度和饱和度混用时顺序很重要
CSS filter 是按书写顺序执行的，grayscale(1) saturate(2) 和 saturate(2) grayscale(1) 渲染结果不同。前者先转全灰再拉饱和（无效，灰度后已无色相可拉），后者先拉饱和再变灰（结果仍是灰的，但中间计算路径不同，极端情况下会影响抗锯齿表现）。
使用场景：做“悬停高亮”时，常想让图片默认灰度、hover 时恢复色彩+微调饱和。正确写法是默认设 grayscale(1)，hover 时用 grayscale(0) saturate(1.2) —— 不要试图在 hover 里只写 saturate(1.2)，那不会取消灰度。
立即学习“前端免费学习笔记（深入）”；
- 所有 filter 函数串联时，浏览器按从左到右顺序逐个应用，不可逆
-
grayscale(1)和sepia(1)都是“去色系”操作，叠加无意义；但grayscale(0.5)+saturate(0.8)这类部分值组合会有细微色调偏移 - IE 完全不支持
filter（除了旧版-ms-filter的简单高斯模糊），如需兼容，得另配 SVG 滤镜 fallback
filter 在 fixed 定位元素上导致模糊边缘撕裂
给 position: fixed 元素加 filter（比如 blur(1px)），在 Chrome 和 Safari 下容易出现边缘像素错位、闪烁或半透明毛边。根本原因是浏览器对 fixed 元素做合成层提升时，filter 触发的离屏渲染与视口滚动不同步。
性能影响比想象中大：哪怕只是 blur(0.5px)，也会强制该元素脱离普通文档流，生成独立合成层，内存占用上升，滚动时 GPU 负载增加。实测在低端 Android 机上，一个带 filter 的 fixed 导航栏会让 60fps 掉到 40fps 以下。
- 临时缓解：加
will-change: filter提前提示合成，但别滥用，否则反而引发更多层 - 更稳方案：用
backdrop-filter替代（仅作用于背景模糊），或改用伪元素 +opacity模拟弱化效果 - 绝对不要对
body或全屏fixed蒙层直接加blur()，那是卡顿重灾区
filter 动画卡顿？别用 transition 直接过渡数值
对 filter 做 transition: filter 0.3s，尤其是涉及 blur() 或多函数组合时，Chrome 会频繁触发重绘而非硬件加速，动画一卡一卡。原因在于 filter 属性本身无法被 GPU 直接缓存，每次数值变化都要重新光栅化整个元素。
真实可用的解法不是“调更快的贝塞尔曲线”，而是绕开 filter 动画本身：用 transform: scale() 模拟模糊感，或用 @keyframes 配合 will-change + 分帧控制，但最省心的是——能静态就静态，能 JS 控制开关就别做连续过渡。
- 只对单个函数做动画稍好些，例如
filter: brightness(1) → brightness(0.7)比blur(0) → blur(2px)流畅 - Firefox 对 filter 动画优化较好，但 iOS Safari 基本放弃治疗，低于 iOS 15.4 的设备几乎必卡
- 如果必须动，优先用
animation+steps(1, jump-end)做分段切换，比平滑过渡更稳
filter。 
