filter: blur()一动就卡因不走gpu合成层，每次变化强制cpu重绘且计算量随半径平方级增长；transition无效主因是未初始化filter、混用函数或display:none中断过渡链；需统一写法、限制范围并配对transform: translatez(0)触发真正升层。
filter: blur() 为什么一动就卡
因为 filter: blur() 不走 GPU 合成层，每次变化都强制重绘（paint），且计算量随模糊半径平方级增长。哪怕只是从 blur(0) 到 blur(2px)，浏览器也得对每个像素做高斯卷积——这活儿全压在主线程 CPU 上，低端安卓 WebView 或旧版 iOS Safari 直接掉帧到 20fps 以下。
transition: filter 0.3s 为什么无效或跳变
常见失效不是语法错，而是漏了关键前提：
- 没显式初始化
filter：默认状态若没写filter: blur(0)，浏览器无法确定起始值，过渡直接退化为“瞬间切换” - 混用了其他
filter函数：比如 hover 时只写filter: blur(5px)，但默认状态是filter: brightness(1.2)，后者会被完全覆盖，导致亮度突变 - 用了
display: none切换：元素被移出渲染树后，filter过渡链中断，再 show 时只能硬跳
想用 filter 动画又不卡，必须做的三件事
不是加 will-change: filter 就能救，得配合底层控制：
- 统一写法：始终把所有
filter值写在同一行，例如filter: blur(0) brightness(1) contrast(1)，hover 时只改数值，不增删函数 - 限制作用范围：用
overflow: hidden包裹模糊容器，避免模糊溢出触发整页重绘；大图模糊优先裁剪后再应用 - 硬件加速要“配对”：单加
will-change: filter效果有限，必须搭配transform: translateZ(0)或backface-visibility: hidden才能真正升层——否则父容器有filter或overflow: hidden，子元素照样被拖进主图层软渲染
比 filter: blur() 更稳的替代方案
真要模糊效果，优先考虑非滤镜路径：
- 背景虚化用
backdrop-filter: blur(8px)（Chrome 84+ / Safari 9+ 支持较好，iOS 15.4+ 才稳定） - 内容遮罩用两层叠加：底层固定模糊图 + 上层透明度渐变遮罩，靠
opacity过渡，完全走 GPU - 动态模糊场景改用 Canvas 或 WebGL 渲染，JS 控制模糊核参数，避开 CSS 滤镜的同步阻塞
最常被忽略的一点：filter 动画的性能瓶颈不在“怎么写”，而在“谁在动”。哪怕一个 div 只有 100×100px，只要它父容器正在滚动或有动画，filter 就会跟着每帧重算——这时候升层也没用，得先切断继承关系。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
