position: absolute的包含块是最近的非static祖先元素（position为relative/absolute/fixed/sticky）的padding box；若无，则为初始包含块（视口）。
position: absolute 的包含块到底是谁？
绝对定位元素的 top/left/right/bottom 不是相对于父元素内容区，而是相对于“最近的已定位祖先”的内边距区（padding box）。这个“已定位祖先”指 position 值为 relative、absolute、fixed 或 sticky 的祖先元素。
常见错误现象：给子元素设 position: absolute，父元素只写了 width 和 height，但没加 position: relative —— 结果元素飞到视口左上角。因为父元素仍是 static，不构成包含块，浏览器只能回退到初始包含块（即视口）。
- 如果 DOM 中存在
<div style="position: relative"><div style="position: absolute">，那么外层 <code>div就是内层的包含块 - 如果中间隔着多个
static元素，跳过它们，继续向上找，直到找到第一个非static祖先或到达 -
transform或perspective非none的祖先也会成为包含块（即使position: static），这是容易被忽略的隐式触发条件 - 解决办法不是强行加
height: 100%，而是确保**包含块本身有确定高度**：可以是固定值（height: 400px）、视口单位（height: 100vh），或父级已设明确高度 - 对
position: absolute元素，其包含块若为position: relative父级，则父级必须有可计算的高度（不能是min-height单独撑开） - Flex/Grid 容器可作为包含块，且能自然传递高度上下文，比纯 block 布局更可靠
- 检查该父容器是否真的构成了子元素的包含块 —— 查看它的
position是否为非static - 如果父容器没定位，但你又不能改结构，可用
transform: translateZ(0)或will-change: transform强制创建包含块（副作用是触发新层叠上下文） - 更稳妥的做法是把绝对定位元素用 Portal 挂载到
下，彻底脱离原层级的裁剪约束 - 这种行为在 iOS Safari 和部分安卓 WebView 中尤其明显，是兼容性雷区
- 调试时可用浏览器开发者工具的“Layout”面板查看元素实际的 containing block 边界（Chrome DevTools > Elements > Layout tab）
- 若需强固定，避免在祖先上使用任何可能创建新包含块的 CSS 属性，或用 JS 监听 scroll 手动重置位置（不推荐，性能差）
为什么百分比高度经常失效？
因为 height: 50% 是相对于包含块的高度计算的，而大多数块级祖先的默认高度由内容撑开 —— 这就形成循环：子元素要算高，得先知道父高；父高又依赖子高。浏览器直接放弃计算，把百分比高度当无效声明处理。
典型场景：想让一个 position: relative 的容器内部的子元素占满高度，但父容器没设显式 height，只靠内容撑开。
立即学习“前端免费学习笔记（深入）”；
overflow: hidden 为什么有时裁不掉绝对定位元素？
关键点：只有当某个元素**既是包含块，又设置了 overflow: hidden**，它才会裁剪其内部的绝对定位子元素。如果只是普通父容器（position: static），哪怕加了 overflow: hidden，也完全不影响 position: absolute 子元素的显示范围。
真实开发中高频问题：下拉菜单、Tooltip、弹窗被意外截断。
fixed 元素的包含块为什么总在视口？
position: fixed 元素的包含块始终是初始包含块（initial containing block），也就是当前视口（viewport），与 DOM 层级完全无关。这意味着它的 top: 0 永远贴浏览器顶部，right: 0 永远贴浏览器右边缘。
但要注意两个例外：当祖先元素设置了 transform、perspective 或 will-change: transform 时，fixed 元素的包含块会变成那个祖先的 padding box —— 这会导致它“粘”在那个祖先内部滚动，而不是随视口固定。
包含块不是抽象概念，它是浏览器布局引擎里真实参与计算的矩形区域。很多“样式没生效”“位置不对”“高度塌陷”问题，根源都在没意识到当前元素的包含块其实不是你以为的那个父元素。
