绝对定位元素脱离文档流，不参与盒模型计算且不影响其他元素布局；其定位参照最近非static祖先（含relative/absolute/fixed/sticky），宽高由top/bottom/left/right及width/height声明优先级决定，百分比值相对包含块，z-index受限于层叠上下文。
绝对定位元素完全脱离正常文档流
不参与盒模型计算，也不影响其他元素的布局位置。父容器设置 position: relative 后，position: absolute 元素会相对于该父容器定位，但它的宽度、高度、margin、padding 等仍存在，只是不再触发文档流中的尺寸分配和位置占位。
- 兄弟元素会“无视”它存在，像它根本没写在 HTML 里一样
-
width和height若未显式设置，默认收缩为内容尺寸（非父容器 100%） -
margin不会与其他元素发生合并（collapse），但也不会推挤任何东西 - 即使设置了
top: 0; left: 0;，它也不会让父容器自动“撑开”高度
absolute 元素的宽高如何确定
取决于是否声明了 top/bottom 或 left/right 配对，以及是否设了 width/height。浏览器按特定优先级解析：
- 若同时指定
left和right，且未设width→ 宽度由两者与包含块计算得出 - 若只设
left和width→right自动计算，不参与布局反馈 - 若啥都没设 → 宽度回退到“shrink-to-fit”，即包裹内容（类似
display: inline行为） - 百分比宽高始终相对于包含块（最近的
position: relative/absolute/fixed祖先），不是视口
z-index 和层叠上下文的关系
z-index 只在同一个层叠上下文内生效。一旦父元素创建了新的层叠上下文（如设置了 opacity: 0.99、transform: translateZ(0)、filter: blur(1px)），其内部所有 position: absolute 子元素的 z-index 都无法越过该父级去和外部元素比较层级。
- 常见陷阱：给弹窗加
z-index: 9999，但父容器有opacity: 0.99→ 弹窗实际被压在底层 - 检测方式：打开 Chrome DevTools 的“Layers”面板，看是否有意外的层叠上下文被创建
- 修复思路：把
opacity或transform移到更外层，或改用background-color: rgba()替代半透明
absolute 元素的包含块怎么找
不是简单找“第一个 position 不是 static 的祖先”，而是严格按规范查找：向上遍历直到找到 position: relative、absolute、fixed 或 sticky 的祖先元素；如果都没有，则包含块是初始包含块（initial containing block），即视口尺寸（不是 或 ）。
立即学习“前端免费学习笔记（深入）”；
-
默认position: static，哪怕设了margin也不会成为包含块 -
transform、perspective、filter等也会创建包含块（CSS Containment Level 2 规范扩展） - 使用
getBoundingClientRect()获取位置时，返回值始终相对于视口，和包含块无关
.container {
position: relative;
width: 300px;
height: 200px;
border: 1px solid #333;
}
.overlay {
position: absolute;
top: 20px;
left: 20px;
background: #ff6b6b;
color: white;
padding: 8px 12px;
}
真正容易被忽略的是：position: absolute 元素虽然脱离流，但它依然受祖先的 overflow: hidden 裁剪，也依然响应 transform 和 will-change 触发的合成层变化 —— 这些行为都发生在布局之后、绘制之前，不属于盒模型范畴，但直接影响视觉表现和性能。
