contain: paint 会强制创建新 containing block，使 position: fixed 元素的定位基准从视口降级为该容器，等效于 absolute；需通过 DevTools 实测滚动行为或移除该声明验证。
contain: paint 本身不破坏 fixed，但它强制创建新 containing block，导致原本依赖视口的 position: fixed 元素被降级为 relative to 该容器 —— 这是规范行为，不是 bug。
contain: paint 怎么悄悄改掉 fixed 的定位基准
浏览器只要见到 contain: paint（或 contain: layout paint、contain: strict），就会为该元素创建新的 containing block 和新的层叠上下文。而 position: fixed 的生效前提，是其 containing block 必须是视口（viewport）。一旦父级有了 contain: paint，fixed 子元素的 containing block 就变成这个父容器的内容区（padding box），结果等效于 position: absolute，不再锚定视口。
- 常见现象：弹窗、返回顶部按钮、全局提示条突然“粘”在父容器右下角，而不是屏幕右下角
- 这不是渲染错乱，而是定位上下文被重置 —— DevTools 的 “Computed” 面板里仍显示
position: fixed，但实际行为已变 - 即使父容器本身是
position: static，只要加了contain: paint，它就自动成为 fixed 子元素的新 containing block
哪些父级样式会让 fixed 更容易翻车
contain: paint 是显式触发者，但还有些隐式条件会协同“封杀” fixed 表现：
-
transform不为none（如transform: translateZ(0)）—— 创建新 containing block，fixed 退化 -
filter或opacity —— 触发独立合成层，fixed 被限制在该层内 -
overflow: hidden在 fixed 元素的任意一个定位祖先上 —— 直接裁剪，z-index 无效 -
contain: layout paint+ 父容器height: auto—— 浏览器静默忽略 containment，但 fixed 仍受其影响（因 containing block 已生成）
怎么验证 fixed 是真失效还是假失效
不能只看 CSS 声明或 computed 样式。必须用 Chrome DevTools 实测行为：
立即学习“前端免费学习笔记（深入）”；
- 打开 Rendering 面板 → 勾选 “Layout Shift Regions” 和 “Paint Flashing”
- 滚动页面，观察 fixed 元素是否随内容一起移动 —— 如果动了，说明它已降级
- 右键 fixed 元素 → “Scroll into view”，再看它的
getBoundingClientRect()是否始终相对于视口（top/left 接近 0 或固定值） - 在 Elements 面板中临时删掉父级的
contain: paint，若 fixed 立刻回归正常，即可确认是它导致
真正能稳住 fixed 的实操路径
要么绕开 containment，要么把 fixed 元素彻底移出干扰链：
- 把 fixed 元素从含
contain: paint的 DOM 子树中移出，挂到document.body底部（React 用createPortal，Vue 用mounted+appendChild） - 移出后改用独立类名（如
.global-toast），避免依赖结构选择器 - 若必须保留在原位置，改用
position: sticky+top: 0替代 —— 它不受 containing block 影响，且在 iOS 键盘弹出时更可靠 - 服务端渲染或 JS 动态插入时，别等 CSS 规则加载完，直接在插入前设
el.style.position = 'fixed'并确保其父级无contain
contain: paint 的定位副作用常被低估，因为它不报错、不警告，只在滚动或交互时悄悄偏移 —— 最容易漏掉的，是那个没写 position: relative 却又加了 contain: paint 的父容器，它既没撑起定位上下文，又截断了 fixed 的视口锚点。
