firefox对定位包含块判定更严格，chrome则较宽容；需确保父容器显式设position: relative，避免回溯到html，并检查transform/filter等意外创建包含块。
Chrome里看着好好的定位，一开Firefox就偏了——大概率不是你写错了，而是Firefox对包含块、层叠上下文或单位解析更严格，而Chrome“宽容”地帮你兜底了。
检查父容器是否显式设了 position: relative
Firefox 对 position: absolute 元素的“最近已定位祖先”判定比 Chrome 更死板：如果父容器是 position: static（默认值），它会直接回溯到 ，而 Chrome 有时会因渲染优化“假装”有包含块。
- 给直接包裹定位子元素的父容器加
position: relative，哪怕它本身不需要偏移 - 避免依赖
body作为定位上下文——body在 Firefox 中可能被视作非标准包含块，尤其当它没设min-height: 100vh时 - 用 DevTools 的 “Computed” 面板点开目标元素，看
offsetParent是谁；如果是html，说明父容器没生效
排查 transform 或 filter 创建了意外包含块
只要某个祖先元素用了 transform（哪怕只是 translateZ(0)）、filter（非 none）或 opacity（position: absolute 子元素的 top/left 参照系突然变成那个祖先，而不是你预期的父容器。
- 临时删掉父级或祖父级的
transform、filter声明，看错位是否消失 - 若必须保留
transform，把position: relative显式加在触发 transform 的那个元素上，确保它同时是定位上下文 - 注意
will-change: transform也会触发同样行为，别把它当“无害提示”
验证 top/bottom 是否混用了 inset 或 vh
Firefox 对 inset 的支持从 102+ 开始，但如果你写了 inset: 0; top: 20px，Firefox 会按规范让 top 覆盖 inset 的上值，而 Chrome 可能忽略冲突；同理，top: 5vh 在横屏/缩放下，Firefox 计算 vh 更保守，容易漂移。
- 禁用混用：
inset和top/left不要共存，选一个体系到底 - 避免
vh用于关键定位：改用dvh（Firefox 104+ 支持）或rem+ 显式html { font-size: 16px } - 用
getBoundingClientRect()在 Firefox 控制台里实测数值，比光看 Styles 面板更准
留意 z-index 被层叠上下文截断
Firefox 对层叠上下文的创建和传播更“教科书”：只要某个祖先用了 transform、opacity: 0.99 或 filter: blur(1px)，它就会强制创建隔离上下文，子元素再高的 z-index 也出不去——Chrome 旧版本可能漏判，让你误以为“没问题”。
- 在 Firefox DevTools 的 Computed 面板里搜 “Stacking Context”，如果目标元素或其任意祖先标了这个，说明
z-index已被锁死 - 降级方案：把需要置顶的元素提到更高层级的 DOM 位置，绕开问题祖先
- 不要靠
!important强推z-index，它解决不了上下文隔离
真正麻烦的不是 Firefox “太较真”，而是它提前暴露了你在 Chrome 里侥幸通过的隐患——比如没声明的包含块、混用的定位属性、或靠 opacity 小数点“蒙混过关”的层叠逻辑。修 Firefox，往往就是把整个定位链重新理清楚。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
