filter 非 none 会强制 fixed 元素的包含块变为该 filter 祖先，使其行为类似 absolute；Chrome DevTools 可见 containing block 变更，blur(0)、brightness(1) 等均触发，修复需移出 DOM 子树、改用 sticky 或 absolute。
filter 会让 fixed 定位“变成 relative”是错觉，实际是降级为 relative 该父级的 absolute
不是真的变成 position: relative，而是 position: fixed 的包含块（containing block）被强制切换成设置了 filter 的祖先元素——此时它行为上等同于 position: absolute，且定位基准不再是视口，而是那个带 filter 的父容器。
这个变化在视觉上常被误读为“fixed 失效”或“变成了 relative”，但 DOM 中 position 计算值仍是 fixed；只是规范要求它必须换锚点。Chrome DevTools 的 Computed 面板里能看到 containing block 指向了某个 div 而非 viewport，这就是关键证据。
哪些 filter 值会触发 fixed 降级
只要 filter 的最终计算值不为 none，就足以触发。哪怕它看起来“没效果”：
-
filter: blur(0)—— 有效，blur(0)≠none -
filter: opacity(1)—— 语法错误（opacity()不是 filter 函数），但部分浏览器会 fallback 或报错，导致计算值非none，同样危险 -
filter: brightness(1)、filter: contrast(1)—— 全部触发 -
filter: unset或filter: none—— 唯一安全组合
为什么 filter 和 transform 效果一样，却容易被忽略
因为 filter 不改变布局、不占空间、也不影响滚动条，开发者很少主动检查它。而 transform 至少可能带来位移或旋转，更容易被肉眼察觉。
立即学习“前端免费学习笔记（深入）”；
排查时容易漏掉的点包括：
- 第三方 UI 库组件（如
el-dialog、uni-popup）内部默认加了filter: drop-shadow(...)或filter: blur(1px) - CSS-in-JS 工具（如 styled-components）动态注入的
filter，在 Elements 面板看不到原始样式，只能靠 Computed 面板确认计算值 -
backdrop-filter同样敏感，尤其在 iOS Safari 中，哪怕值是backdrop-filter: blur(0)也会触发
修复 fixed 时 filter 相关的实操建议
不要试图用 filter: none !important 覆盖——这常因优先级或继承链失败，且破坏原有视觉效果。真正可行的路径只有两条：
- 把 fixed 元素从带
filter的 DOM 子树中移出，挂到document.body下：Vue 用<Teleport to="body">，React 用createPortal，纯 JS 用document.body.append(el) - 放弃
fixed，改用position: sticky：比如top: 0或bottom: 0，它完全不受filter、transform影响，现代浏览器支持率已超 98% - 若必须保留在局部结构内且需任意坐标（如右上角 + 偏移 12px），用
position: absolute+ 父容器position: relative，这是最稳定、零 JS、无兼容性风险的替代方案
真机测试时，iOS 上 filter 引发的 fixed 错位常在软键盘弹出后才暴露——这时连 sticky 都可能跳动，得靠 resize 事件监听视口高度变化做兜底。
