应使用 saturate(0%) 到 saturate(100%) 实现悬停去灰效果，避免 grayscale() 兼容性问题；需显式声明 transition: filter .3s ease；添加 will-change: filter 启用硬件加速；响应式下应将滤镜 applied 到包裹容器而非 img 标签本身。
filter 用 grayscale(0) 和 saturate(100%) 的区别
悬停变彩色，本质是取消灰度效果。但直接写 grayscale(0) 不一定管用——因为初始状态如果是 grayscale(1)，过渡时浏览器会插值计算中间值，而某些旧版 Safari 对 grayscale() 的动画支持不完整，容易卡在偏灰状态。
更稳的写法是统一用 saturate() 控制：初始设 saturate(0%)（完全去色），悬停设 saturate(100%)。它在 Chrome、Firefox、Edge 和现代 Safari 中动画平滑，且兼容性更好。
-
saturate(0%)等效于黑白，saturate(100%)是原始饱和度，语义清晰 - 避免混用
grayscale()和saturate()，会导致 CSS 层叠时计算逻辑冲突 - 如果图片本身带滤镜链（比如还加了
brightness()），必须把所有滤镜写在一行里，否则过渡会失效
transition 必须显式声明 filter 才生效
CSS 过渡不会自动监听 filter 变化。哪怕你写了 transition: all .3s，在部分浏览器（尤其是 Safari 15.4–16.3）中，filter 仍可能无动画。
正确做法是单独声明 transition 属性，且明确列出 filter：
立即学习“前端免费学习笔记（深入）”；
img {
filter: saturate(0%);
transition: filter .3s ease;
}
img:hover {
filter: saturate(100%);
}
- 不要依赖
all，它在滤镜过渡上不可靠 -
ease比linear更自然，人眼对饱和度变化敏感，缓动能降低突兀感 - 过渡时间别设太短（如
.1s），iOS 上可能来不及渲染中间帧，看起来像直接跳变
图片父容器需触发硬件加速，否则动画掉帧
纯 CSS 滤镜过渡在滚动区域或低性能设备上容易卡顿，尤其 Android WebView 或旧 iPad。根本原因是浏览器没启用 GPU 加速，全程走 CPU 合成。
给图片或其直接父容器加 transform: translateZ(0) 或 will-change: filter，能强制启用硬件加速：
img {
filter: saturate(0%);
transition: filter .3s ease;
will-change: filter;
}
-
will-change: filter比translateZ(0)更精准，只提示浏览器“这个元素的 filter 会变” - 别滥用
will-change，只加在真正需要过渡的元素上，否则可能引发内存或渲染异常 - 如果图片在
position: fixed容器里，还要确认父级没设置overflow: hidden，否则滤镜裁剪可能意外截断边缘
响应式场景下 filter 缩放失真问题
当图片用 max-width: 100% 或 object-fit: cover 响应式缩放时，悬停过渡可能出现颜色不均、边缘泛灰——这是因为滤镜作用于渲染后的像素，缩放后采样方式改变，saturate() 插值精度下降。
解决思路不是禁用缩放，而是让滤镜始终基于原始分辨率计算：
- 给图片包裹一层
<div>，设 <code>overflow: hidden，图片用width: 100%; height: 100%; object-fit: cover - 把
filter和transition写在包裹层上，而不是<img alt="CSS图片滤镜过渡_悬停时从黑白变彩色的视觉技巧" >标签本身 - 这样滤镜作用于容器（尺寸固定），图片只是内容，缩放不影响滤镜插值质量
复杂点在于：这种写法会让 :hover 必须作用于容器，不能只 hover 图片；而且如果容器有内边距或边框，得额外调整尺寸对齐。这些细节容易被忽略，一动就露白边或错位。
