css filter 失效主因是 overflow: hidden 剪裁、层叠上下文隔离、ie 不支持、跨域限制及组合顺序错误；性能卡顿源于未启用硬件加速或高开销函数叠加；动态修改需用对象维护而非字符串拼接。
CSS filter 是最直接、性能最好、也最容易翻车的滤镜方案——它不是“能不能加”，而是“加完会不会被裁掉”“动效卡不卡”“旧浏览器用户看到啥”。
为什么 filter 有时没效果？常见失效场景
不是代码写错了，而是这些地方悄悄拦住了你：
-
overflow: hidden父容器会剪掉blur()或drop-shadow()溢出的部分，哪怕只模糊 1px，也可能看不见边缘 -
transform: scale(1)或will-change: transform之类触发层叠上下文后，filter可能只作用于子层，而非整个元素渲染结果 - IE 完全不支持
filter（包括 IE11），用@supports (filter: blur(1px))包裹才安全，别信“现代项目不用管 IE”——有些政企内网真还在跑 - 图片跨域但未配 CORS，
filter能显示，但后续若用canvas读取该图数据，会直接报SecurityError
filter 组合顺序影响最终效果
多个函数不是“叠加权重”，而是按书写顺序逐层处理像素。比如：
img { filter: brightness(0.8) contrast(2) blur(2px); }
等价于：先压暗 → 再拉对比 → 最后模糊。反过来写，模糊后的低对比图像再提亮，视觉差异明显。
-
blur()放最后，避免其他操作在模糊前引入噪点或锯齿 -
grayscale()或sepia()建议放最前，否则亮度/饱和度调整可能在彩色空间里做无谓运算 -
drop-shadow()不是“给图片加阴影”，而是对整个滤镜链输出结果加投影，所以它必须写在最后才能包住所有效果
hover 动效卡顿？不是 JS 问题，是硬件加速没跟上
直接写 transition: filter 0.3s 在低端设备或大量图片时容易掉帧。真正稳的写法是：
- 给元素加
will-change: filter（仅在 hover 前触发，避免常驻开销） - 或者用
transform: translateZ(0)强制升层，让滤镜计算走 GPU - 慎用
blur()+hue-rotate()组合动画——两者都是高开销操作，同时过渡极易卡顿 - 测试时打开 Chrome DevTools → Rendering → 勾选 “Paint flashing”，看是否每帧都在重绘；如果大片绿色闪，说明
filter触发了软件渲染回退
想动态改滤镜？别直接拼字符串
用 JavaScript 修改 style.filter 时，手写字符串容易漏空格、错单位、覆盖已有值：
img.style.filter = 'blur(2px) brightness(1.1)'; // OK<br>img.style.filter += ' contrast(1.3)'; // 危险！可能变成 'blur(2px) brightness(1.1)contrast(1.3)'（缺空格）
- 用
getComputedStyle(img).filter读当前值再解析，太重，不推荐 - 更稳妥的是维护一个对象，比如
let filters = { blur: '2px', brightness: '1.1' }，然后Object.entries(filters).map(([k, v]) => `${k}(${v})`).join(' ') - 需要开关某一项时（如点击切换灰度），直接删 key 再重生成，比正则替换字符串可靠得多
最常被忽略的一点：滤镜不是“视觉糖”，它是渲染管线中真实的一环。blur 半径超 10px、连续叠加 5 个函数、在滚动区域里大量使用——这些操作不会报错，但会在用户手机上默默吃掉帧率。上线前务必在真机上滑动测试，别只盯着桌面 Chrome 的 60fps。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
