blur()滤镜transition默认不生效，因其属非可动画属性，需配合will-change:filter、统一单位及完整filter值才能实现平滑过渡，否则浏览器直接跳变。
blur() 滤镜的 transition 为什么默认不生效
因为 blur() 是 SVG 滤镜函数，属于“非可动画属性”，CSS 规范里明确把它归在 filter 这个复合属性下，而浏览器对 filter 的过渡支持依赖于实现细节——Chrome/Edge 从 v100+ 开始支持，Firefox 直到 v115 才完整支持，Safari 则至今（v17.6）对 blur() 的 transition 有延迟或跳变。
直接写 transition: filter 0.3s 看似合理，但实际会卡顿、跳帧，甚至悬停瞬间就完成模糊，毫无过渡感。
- 必须用
will-change: filter提前告知浏览器该元素的filter会变化，否则渲染线程不预分配资源 - 避免同时过渡多个滤镜（比如
blur()+brightness()），会显著增加计算负担 - 移动端 Safari 建议降级为
opacity过渡，或改用@keyframes+animation替代transition
正确写法：transition + filter + will-change 组合
核心不是“加 transition”，而是让浏览器知道“这个 filter 要动”，并限定只动 blur() 值本身。CSS 中不能单独过渡 blur()，只能过渡整个 filter 属性，所以初始值和悬停值都得显式写出完整函数，且参数类型、数量、单位必须严格一致。
错误示例：filter: blur(0); → filter: blur(8px) contrast(1.2);（参数结构突变，过渡中断）
立即学习“前端免费学习笔记（深入）”；
- 初始态写成
filter: blur(0px) brightness(1);，悬停态对应改成filter: blur(6px) brightness(1); - 所有数值统一用
px单位（不能混用px和无单位数字），否则 Chrome 会拒绝过渡 - 加上
will-change: filter;到 hover 元素上，但不要加在父容器或全局选择器里，避免过度触发重绘 - 如果图片是响应式（
max-width: 100%），blur 效果在缩放后可能失真，建议包裹一层固定尺寸的div并设overflow: hidden
兼容性 fallback：用 @keyframes 替代 transition
当目标用户包含大量 iOS 用户，或发现 transition 在 Safari 下始终跳变时，@keyframes 是更稳的选择——它绕过了浏览器对 filter 过渡的内部判断逻辑，强制逐帧计算。
关键点在于：动画必须定义起止两帧，且 blur() 参数必须可插值（即同单位、同数量），否则动画会直接跳到终点。
- 定义动画：
@keyframes blur-in { from { filter: blur(0px); } to { filter: blur(4px); } } - 悬停触发：
img:hover { animation: blur-in 0.4s ease-out forwards; } - 移出时需反向动画或重置：
img { animation: none; } img:hover { animation: blur-in 0.4s ease-out forwards; }，否则鼠标快速进出会导致动画堆积 - 注意
forwards会让样式停留在最后一帧，所以必须配对写回退规则，例如img:not(:hover) { filter: blur(0px); }
性能陷阱：blur 值越大，GPU 占用越高
blur(2px) 和 blur(8px) 看似只差 6 像素，但算法复杂度是平方级增长——blur(8px) 的采样半径约是 blur(2px) 的 4 倍，像素计算量接近 16 倍。尤其在中低端 Android 设备上，悬停瞬间掉帧明显。
- 推荐模糊范围控制在
0–6px之间，视觉差异足够，性能损耗可控 - 避免对高分辨率图（如 >2000px 宽）直接应用 blur，先用
object-fit: cover缩放到视口尺寸再加效果 - 开启硬件加速不等于解决一切：
transform: translateZ(0)对 filter 动效无效，真正有效的是will-change: filter或contain: paint - 用 Chrome DevTools 的 Rendering 面板勾选 “Paint flashing”，可直观看到 blur 区域是否频繁重绘
blur 的过渡不是“加个 transition 就行”，而是浏览器渲染管线的一次协商——你得说清动什么、怎么动、动多快，它才肯配合。漏掉 will-change，或者单位不统一，它就直接放弃过渡，连招呼都不打。
