fixed定位的包含块必须是视口，不参考父级容器；其宽高、定位均基于视口计算，不受父元素padding/margin/border或transform/filter等影响。
fixed定位天生就不参考父级容器
它根本不是“无法相对于父级”，而是规范明确禁止——position: fixed 的包含块（containing block）**必须是视口（viewport）**，不是父元素，也不是任何祖先元素。哪怕父容器写了 width: 300px、padding: 20px、transform: translateZ(0)，对 fixed 元素的尺寸计算和定位偏移都毫无影响。
常见误判是看到父级有 padding 或 transform，就以为 fixed 元素会跟着偏移。实际它只认 left: 20px 是“离屏幕左边 20px”，不是“离父容器内容区左边 20px”。
想让元素相对父容器“固定”，该用什么
如果你要的效果是“在父容器内不随滚动移动”，position: fixed 不是正确工具——它生来就是为锚定视口设计的。你应该选：
-
position: sticky：支持top/bottom偏移，滚动到临界点才“粘住”，现代浏览器全覆盖，且完全不受transform、filter干扰 -
position: absolute+ 父容器设position: relative：真正在父级坐标系内定位，行为可预测，适合弹窗、浮层等局部固定场景 - 纯 JS 方案（仅兜底）：监听
scroll+resize，用getBoundingClientRect()动态算位置；但需严格节流，且软键盘弹出时视口高度突变，容易错位
为什么有人觉得fixed“能”相对父级
那其实是被干扰了——当某个祖先元素设置了以下任一属性，就会悄悄创建新包含块，使 position: fixed **退化为相对该祖先定位**，视觉上像“绑定了父级”：
立即学习“前端免费学习笔记（深入）”；
-
transform值不为none（包括translateZ(0)、scale(1)） -
filter值不为none（哪怕blur(0)、opacity(0.99)） -
backdrop-filter、will-change: transform、perspective - iOS Safari 中的
overflow-scrolling: touch
这不是 bug，是 CSS 规范强制行为。用 Chrome DevTools 的 Computed 面板查 “Containing Block”，一眼就能确认基准是否已从 viewport 变成某个 div。
移动端 fixed 错位别只查 CSS
iOS Safari 和部分 Android WebView 中，position: fixed 在软键盘弹出、页面缩放或横竖屏切换时会临时失效——这不是样式问题，是系统级渲染策略：
- 键盘唤起时，iOS 会解除 fixed 锚定，导航栏“掉下来”；此时
position: sticky更稳 - 缩放后错位，往往因
<meta name="viewport">缺少maximum-scale=1.0和minimum-scale=1.0，仅user-scalable=no无效 - 真机测试不可替代：缩放 + 键盘 + 横竖屏三者叠加，才是 fixed 最容易暴露问题的场景
真正难处理的，是那些你没写但第三方组件（如 Ant Design Drawer、轮播图）内部默认加的 transform 或 backdrop-filter——它们静默创建包含块，而你根本看不到源码里那一行。
