绝对定位元素的 width/height 默认参考最近的已定位祖先，若无则回退至初始包含块（通常是视口）；不设 position: relative 的父容器时，width: 100% 或 height: 100% 即按视口尺寸计算，但该行为不可控且易被中间已定位祖先劫持。
绝对定位元素的 width/height 默认参考谁？
不设 position: relative 父容器时，width: 100% 或 height: 100% 的 position: absolute 元素，会直接参考**初始包含块（通常是视口）**，而不是父元素。这看似“基于视口”，但实际是 fallback 行为，不可控且易被祖先劫持。
常见错误现象：
- 父容器没设
position: relative，子元素width: 100%却撑满整个屏幕 - 中间某层祖先意外加了
position: absolute，导致子元素尺寸突然参考它而非视口
所以，“基于视口计算”不能靠“不设父级定位”来赌，默认行为太脆弱。
用 vw/vh 直接写死宽高是否真等于“视口计算”？
是，但仅限于数值来源；不是语义上的“绑定视口尺寸”。width: 50vw 确实是视口宽度的 50%，但它和元素自身原始比例无关——缩放时宽高比会变，且无法响应设备像素比或 zoom 变化。
立即学习“前端免费学习笔记（深入）”；
使用场景有限：
- 做固定比例的遮罩层（
width: 100vw; height: 100vh） - 图标距右下角 5% 距离（
right: 5vw; bottom: 5vh） - 但若需等比缩放内容本身（比如一个按钮随窗口变小而整体缩小），仅靠 vw/vh 不够
注意：vw 和 vh 在 iOS Safari 中曾有全屏视频模式下视口计算异常的问题，2026 年已修复，但仍建议在关键路径加 @supports (width: 100vw) 降级兜底。
如何让 top/left 也真正“基于视口”并保持稳定？
只写 top: 10vh; left: 5vw 是最直接的方式，但它依赖两个前提：
- 父容器必须是
position: relative或其它非static值，否则偏移值可能被更近的已定位祖先覆盖 - 不要混用
position: fixed—— 它虽然强制锚定视口，但会脱离文档流且无法被父容器 padding 影响，left: 5vw在 fixed 下仍有效，但transform和z-index行为更复杂
容易踩的坑：
- 写了
top: 20%却发现是相对于父容器高度，不是视口——因为 % 在 absolute 元素中，参考的是**最近已定位祖先的高度**，不是视口 - 想用
calc(50vh - 20px)居中一个 40px 高的元素，结果在小屏上负值溢出——要加min-height或 JS 校验
需要动态适配时，为什么 calc() + JS 比纯 CSS 更可靠？
calc() 支持混合单位（如 calc(50vw - 20px)），但它的计算发生在样式解析阶段，无法感知元素自身尺寸或运行时状态。一旦你要做“让元素始终占视口宽高的最小比例”或“缩放时同步调整 top/left”，就必须用 JS。
典型做法：
- 监听
window.resize，用Math.min(window.innerWidth / 1920, window.innerHeight / 1080)算缩放系数 - 把该系数同时应用到
transform: scale()和top/left的 inline style 上（注意：不能只缩放元素，位置也要同比例缩放） - 用
transform-origin: 0 0保证左上角为缩放原点，避免偏移
关键细节：CSS 的 transform: scale() 不影响文档流，也不触发重排，但会改变元素的渲染尺寸——这意味着其子元素的 em、rem 计算也会被缩放，这点常被忽略。
