top/left百分比参照最近的非static定位祖先（即position为relative、absolute或fixed的包含块）的高度或宽度计算；若无，则退至初始包含块（通常为视口），但行为不可靠。
top/left 百分比到底参照谁计算？
不是父元素内容区，不是视口，更不是你“以为”的那个容器——它严格按 CSS 规范找「包含块（containing block）」。对 position: absolute 元素来说，这个包含块是最近的 position 不为 static 的祖先元素（即 relative、absolute 或 fixed）；若找不到，就退到初始包含块（通常是视口），但此时行为不可靠，尤其在 iframe 或缩放场景下容易错位。
常见错误现象：top: 50% 没居中，反而卡在顶部附近；换了个外层 wrapper 后位置突变；移动端 Safari 中定位延迟生效。
- 务必给绝对定位元素的直接父容器加
position: relative（哪怕它本身不偏移），这是最简单、最可控的建立包含块方式 - 避免让百分比依赖
body或html的高度——它们默认是auto，导致height: 100%实际为 0，top: 50%就等于0px - 用
min-height: 100vh替代height: 100vh，规避 Safari 渲染延迟问题
为什么 top: 50% + transform: translateY(50%) 跑偏了？
因为 top: 50% 是把元素**上边缘**移到包含块高度一半的位置，而 transform: translateY(50%) 是再把自己**向下移动自身高度的 50%**，结果是下移了「父高一半 + 自身高一半」，远超预期。
真正垂直居中要写成：top: 50%; transform: translateY(-50%)，负号不能漏。
-
transform的百分比始终基于元素自身尺寸，和定位属性的百分比来源完全无关——这点必须分清 - 不要混用
left: 50%和transform: translateX(50%)，否则横移量是「父宽一半 + 自身宽一半」 - 动画中优先用纯
transform偏移，避免触发重排；top/left改变会强制浏览器重新计算布局
包含块高度为 0，百分比就失效？
是的。top 和 bottom 的百分比值，是相对于包含块的**高度**计算的。如果包含块高度是 auto（比如未设 height 或 min-height 的 div），那它的计算高度就是 0，top: 20% 就等于 0px，元素根本不动。
典型场景：父容器只写了 width: 100%，没管高度；或用了 flex 布局但没约束主轴尺寸。
- 给包含块显式设置
height、min-height或max-height，哪怕只是min-height: 100vh - 避免用
margin-top: 50%模拟垂直偏移——它参照的是父容器宽度，不是高度，逻辑错乱 - 如果元素宽高不固定（如纯文字块），
transform仍能可靠工作；margin-类方案在未知尺寸时基本失效
viewport 缩放时定位跑偏，怎么稳住？
视口缩放（Ctrl+滚轮、iOS 捏合）不触发 resize 事件，但会改变设备像素比，导致 px 定位等比缩放，而父容器仍按逻辑像素计算，视觉错位就发生了。百分比定位本身不免疫这个问题——它只对包含块生效，而缩放可能让包含块的渲染尺寸失准。
- 确保
<meta name="viewport">存在且完整，例如：<meta name="viewport" content="width=device-width, initial-scale=1.0"> - 让包含块锚定视口：给
html, body { height: 100%; margin: 0; }，再配合min-height: 100vh - 微调类偏移优先用
transform: translate()，它的百分比基于自身尺寸，缩放时不变形 - 复杂场景可监听
visualViewportAPI 补偿缩放偏移，但注意兼容性
最常被忽略的一点：包含块不是“父元素”，而是“最近的非 static 定位祖先”；很多问题根源不在子元素写法，而在父级没加 position: relative —— 这个动作轻量，却决定了整个百分比定位链是否可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
