filter非none会强制创建新包含块，使fixed元素降级为相对祖先定位；可通过DevTools的Containing Block字段及逐层检查filter/transform/backdrop-filter/opacity快速定位，并优先将filter移至html根元素修复。
filter非none会强制创建新包含块
只要任意祖先元素的 filter 计算值不是 none（哪怕 filter: blur(0)、filter: opacity(0.99)），浏览器就必须为它创建一个新的包含块（containing block）。此时 position: fixed 元素不再锚定视口，而是降级为相对于这个祖先元素定位——行为完全等同于 position: absolute。
这不是 bug，是 CSS Containing Block 规范明确要求的行为。Chrome DevTools 的 Computed 面板里，“Containing Block”字段一旦显示某个 div 而非 “Viewport”，就说明已被劫持。
怎么快速定位哪个祖先触发了问题
打开 Elements 面板 → 选中失效的 fixed 元素 → 切到 Computed 标签页 → 点右上角连续箭头逐层向上跳转父节点，每层都检查：
-
filter是否为none -
transform是否为none（注意：translateZ(0)、scale(1)都算） -
backdrop-filter是否非none -
opacity是否小于1
只要其中任一属性不满足“无效果”条件，就可能成为罪魁祸首。
立即学习“前端免费学习笔记（深入）”；
修复时优先把filter移到html上
规范明确指出：filter 作用在 html 元素上，不会为后代的 fixed 或 absolute 创建新包含块。这是副作用最小的解法：
- 错：
body { filter: grayscale(1); }→ 污染所有后代fixed元素 - 对：
html { filter: grayscale(1); }→ 视觉效果不变，fixed仍锚定视口
注意：html 自身若已设 transform 或 backdrop-filter，那它自己就成了新包含块，此时移 filter 也无效。
实在不能改CSS就得动DOM结构
当父容器由第三方库控制（比如弹窗加了 backdrop-filter），或微前端中主应用强加了 transform，CSS 层面无法修改时，必须从 DOM 结构入手：
- React：用
createPortal渲染到document.body - Vue：在
mounted中调用document.body.append(this.$el) - 纯 HTML：手动把
<div class="fixed-btn"> 移到 <code>底部关键提醒：
z-index要显式设高（如z-index: 2147483647），选择器不能依赖原 DOM 路径（比如别用.modal .fixed-btn，改用.global-fixed-btn）。真正难处理的是多层嵌套 + 多框架共用 DOM 的场景，这时候定位基准已经不是“有没有”的问题，而是“谁有权决定包含块”的权限问题。
