absolute元素找不到包含块时，会以视口为初始包含块，top/left等值相对于浏览器窗口左上角计算，滚动时位置固定不动。
absolute元素找不到包含块时会怎样
当position: absolute元素向上查找，发现所有祖先都用position: static（即没显式设过relative/absolute/fixed/sticky），它就失去参照，退回到初始包含块——也就是视口（viewport）边界，等效于以为参考。这时top/left等值会相对于浏览器窗口左上角计算，滚动时位置固定不动（和fixed视觉类似，但行为不同）。
常见错误现象：
• 弹窗或下拉菜单意外“飞”到页面左上角
• right: 0没贴父容器右边缘，反而贴浏览器右边缘
• 滚动时定位元素跟着动（说明它确实没被正确限制在某个祖先内）
- 检查路径：从目标元素开始，逐级看
parentNode的computedStyle.position是否≠static - 最简修复：给直接父容器加
position: relative（不改变布局，只提供包含块） - 注意：
position: relative本身不触发新层叠上下文，除非同时设了z-index或opacity等属性
relative元素的包含块是它自己原来的位置
position: relative元素的包含块，不是它的父元素，而是它**在正常文档流中原本占据的那个矩形区域**——也就是它没偏移前的 content box。所以top: 20px是相对于那个“原位框”的顶部往下移20px，left: 10px是相对于原位框左边往右移10px。
这意味着：
• 它仍占据原始空间，不影响后续元素流布局
• 百分比宽高（如width: 50%）依然按父元素内容区计算，不是按它自己的“原位框”
• transform-origin默认也是基于这个原位框中心
- 不要误以为
relative的包含块是父元素——那是absolute才有的逻辑 - 如果想让子元素
absolute以它为参照，必须显式设position: relative（哪怕只是position: relative不带偏移） -
relative元素设overflow: hidden，不会裁剪它自己偏移后溢出的部分（因为偏移不脱离文档流）
fixed和sticky的包含块分别是视口和滚动祖先
position: fixed的包含块永远是视口（viewport），和DOM结构完全无关。哪怕把它塞进一个transform: scale(0.5)的容器里，它也不会缩放或跟随滚动——因为它锚定的是屏幕坐标系。
position: sticky则复杂些：它的包含块是**最近的滚动祖先的内容区**（通常是父<div>，也可能是<code>或）。只有当该祖先发生滚动，且元素到达阈值（由top/bottom等定义），它才“粘住”。
-
fixed元素不受transform、perspective或filter影响（它们创建新的包含块，但fixed无视） -
sticky必须配合top/bottom等阈值使用，否则退化为relative - 若父容器
overflow: hidden但没滚动条，sticky不会触发——它需要可滚动的上下文
百分比值的计算基准全看包含块
宽度width、内边距padding、外边距margin这些属性的百分比值，一律相对于包含块的**宽度**计算；高度height和max-height的百分比，则依赖包含块的**高度是否明确**（非auto）。
典型陷阱：
• 给absolute子元素设width: 100%，结果撑不满父容器——因为父容器没设高度，包含块高度是auto，百分比高度失效
• padding-top: 50%在relative元素里生效，但在absolute元素里可能意外变大——因为它的包含块可能是整个视口
- 想让
absolute元素的height: 100%有效，必须确保其包含块（即最近非static祖先）有明确高度（如height: 400px或min-height: 100vh） -
margin和padding的百分比永远按包含块宽度算，和方向无关（padding-top: 10%= 包含块宽度的10%） - 用
aspect-ratio替代padding-top技巧，能避开包含块高度不确定的问题
Containing Block字段（Chrome 120+支持直接显示）。但更根本的，是养成“写absolute前先找或造一个relative父容器”的习惯——这比事后排查包含块快得多。
