绝对定位元素的宽高百分比参照其最近非static祖先的padding box；若该祖先宽高为auto，则百分比失效，导致尺寸异常，尤其在iOS Safari中更敏感。
绝对定位元素的百分比宽高到底参照谁
绝对定位元素的 width 和 height 百分比，不是按最近有宽度/高度的父容器算，而是严格按其**包含块（containing block）**计算——这个包含块是它最近的、position 不为 static 的祖先元素的 padding box（含 padding，不含 margin）。这和普通流内元素的 content box 参照完全不同。
常见误解是“只要父级设了 position: relative，子元素写 width: 50% 就一定按父宽一半来”，但实际结果可能出人意料：
- 如果父级
position: relative但自身width: auto（比如只靠内容撑开），那它的包含块宽度可能仍是视口宽或上层容器宽，50%就会远超预期 - 如果父级设置了
padding，而子元素又用了box-sizing: border-box，那width: 100%会刚好填满父级 padding box，看起来“没留边”，其实完全正确 - 父级若同时有
transform（哪怕只是translateZ(0)），在部分浏览器中会触发新包含块，导致百分比基准突变
为什么写了 position: relative 还是不生效
写了 position: relative 却发现子元素的 top: 20% 或 height: 80% 像没写一样，大概率是父级本身没有可计算的尺寸基准。绝对定位不豁免百分比依赖——它只是换了参照对象，不代表能无视尺寸链断裂。
检查步骤要一层层来：
- 用开发者工具选中父级 → 看
Computed面板里的width和height：如果是auto，那子元素的百分比就是0px或退化为内容高度 - 确认父级是否被
display: inline、float或position: absolute干扰，这些会让它无法成为稳定包含块 - 注意 Flex 容器：即使父级
position: relative，若它同时也是display: flex，且子元素未设align-self: stretch，height: 100%依然不会拉伸
absolute + 百分比在移动端的兼容雷区
iOS Safari 对绝对定位下的百分比计算更敏感，尤其涉及 vh 和滚动时。比如一个 position: absolute; height: 100% 的弹窗，在地址栏收起后可能突然变矮——因为它的包含块（通常是 body）高度被重算，而 body 自身又没设固定高。
更隐蔽的问题是 100dvh 和 100vh 混用：
-
height: 100dvh在支持它的浏览器里能响应地址栏变化，但老版本 iOS 完全不识别，直接当无效声明忽略 - 如果父级用了
100dvh，子元素再写height: 50%，那这个 50% 就是按动态视口算的——一旦地址栏展开，子元素高度会跟着缩，而不是保持比例 - 避免在
position: absolute元素里嵌套另一层position: absolute并依赖双重百分比，链路越长，iOS 上越容易失准
调试时最容易漏掉的一环
很多人查了半天，最后发现是父级的 overflow: hidden 或 clip-path 把超出部分裁掉了，看着像“没生效”，其实是渲染了但被切了。还有更隐蔽的：contain: layout 或 contain: paint 会限制包含块边界，让百分比计算提前截断。
真正关键的不是“有没有写 position: relative”，而是打开开发者工具，逐级点开父元素，盯着 Computed → width / height 看真实像素值——只要其中一个是 auto，那所有后代的百分比尺寸就注定不可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
