Firefox中filter不生效主因是误用-webkit-前缀、SVG滤镜作用域限制及color-adjust默认降级；应只用标准filter、内联SVG滤镜并设color-adjust: exact。
filter 属性在 Firefox 里不生效？先看是否用了过时的 -webkit- 前缀
Firefox 从 35 版本起就原生支持 filter，不需要 -moz-filter；而 Chrome 早在 18 版本就支持标准 filter。现在还加 -webkit-filter 不仅多余，反而可能干扰解析——尤其当它和标准写法并存时，某些旧版 Safari 会优先认前缀版，导致 Chrome/Firefox 意外降级到低效实现。
常见错误现象：filter: blur(2px); 在 Firefox 完全没效果，但加了 -webkit-filter: blur(2px); 后却“好了”——这其实是误判：真正生效的是后加的前缀版，而标准属性被忽略或覆盖了。
- 只保留标准
filter，删掉所有-webkit-、-moz-等前缀 - 若需兼容 IE（已基本淘汰），用
@supports (filter: blur(1px))做特性检测，而非前缀 - 注意：Firefox 对
filter: url(#svg-filter)的支持比 Chrome 更严格，ID 必须在同一文档内且未被 shadow DOM 隔离
SVG 滤镜 fallback 在 Chrome 和 Firefox 表现不一致？关键在 url() 写法和作用域
当用 filter: url(#myblur) 引用 SVG 滤镜时，Firefox 要求该 <filter> 元素必须在当前 HTML 文档内（或通过 <use> 显式引入），而 Chrome 允许跨 iframe 或外部文件引用（只要同源）。这意味着你写的 fallback 很可能只在 Chrome 里“看起来正常”，在 Firefox 里直接静默失败。
- 把 SVG
<filter>放在页面顶部<body>内，确保所有元素都能访问到 - 避免用
url(/assets/filters.svg#myblur)这类外部路径——Firefox 不支持 - 如果必须复用，用
<object type="image/svg+xml" data="filters.svg">加载，并用 JS 注入到 DOM，再调用filter: url(#myblur)
性能差异：Chrome 对 filter 动画更激进，Firefox 更保守但更稳定
filter 动画在 Chrome 中常被自动提升为合成层（composited layer），导致内存占用突增；Firefox 则默认不提升，动画更卡但内存平稳。这不是 bug，是渲染策略差异——意味着你写的 transition: filter 0.3s 在两浏览器中实际走的管线完全不同。
立即学习“前端免费学习笔记（深入）”；
- 对高频动画（如 hover 模糊），在 Chrome 中建议加
will-change: filter显式提示，但只在触发时设置，用完即删 - Firefox 下若发现动画掉帧，可尝试用
transform: translateZ(0)强制创建新层，但仅限必要场景 - 避免同时 animating
filter和opacity——两者都触发合成，在 Firefox 中易引发重绘抖动
color-adjust / print-color-adjust 影响 filter 渲染？是的，而且 Firefox 默认开启
当页面启用打印样式或系统深色模式适配时，Firefox 默认启用 color-adjust: economy（等价于 print-color-adjust: economy），它会强制降级部分滤镜效果，比如把 contrast(2) 截断为 contrast(1.5)，而 Chrome 默认是 exact。这个行为不报错、不警告，只悄悄变弱。
- 明确写
color-adjust: exact覆盖默认行为，尤其在需要精确视觉控制的场景 - 不要依赖
@media (prefers-color-scheme: dark)单独调整 filter 值——它和 color-adjust 冲突时，后者优先级更高 - 测试时务必在 Firefox 的「响应式设计模式」中切换「模拟颜色方案」+「禁用硬件加速」双开，才能暴露真实问题
事情说清了就结束。最常被忽略的不是语法，而是 Firefox 对作用域和 color-adjust 的默认约束——它们不报错，只让效果变淡、变慢、变不可控。
