top百分比参照对象取决于position属性：absolute时参照最近非static祖先的内容区高度，relative时参照元素自身高度。
top百分比参照谁？absolute 和 relative 完全不同
写 top: 50% 却没动，或动得离谱，第一反应不该是“CSS bug”，而是立刻确认元素的 position 值和它的包含块高度。因为：top 百分比根本不是统一按父容器高算的。
关键区别：
-
position: absolute的top: 50%→ 参照**最近的非-static 祖先（如position: relative的父容器）的内容区高度**（不含 border，含 padding） -
position: relative的top: 50%→ 参照**元素自身的 height**，跟父容器尺寸毫无关系
常见错误：给一个 height: auto 的 div 设 position: relative; top: 50%，结果等于 top: 0——因为自身高度是 0。
父容器高度为 0，top 百分比就等于没写
绝对定位元素脱离文档流，不会撑开父容器。如果父容器没设 height 或 min-height，又没其他内容撑高它，那它的 computed height 很可能只有几像素（比如仅来自 padding-top: 5%，但 5% 的基准又是 0），top: 30% 就算出来不到 1px。
实操建议：
- 用开发者工具检查父容器的
Computed → height，别只看 Styles 面板里写的值 - 临时加一句
height: 400px或min-height: 80vh，立刻验证是否是高度塌陷问题 - 避免靠
padding-top或margin-top“假装撑高”——它们不参与top百分比计算
定位基准被 transform / filter 暗中劫持
只要父元素写了 transform（哪怕只是 transform: translateZ(0)）、filter、will-change 或 opacity: 0.99，它就会创建一个新的 containing block。此时子元素的 top 不再以父元素的 padding box 为原点，而是以这个新块的 border box 为准。
现象：
- Chrome 里位置准，Safari 里偏 2px，旧安卓 WebView 直接错位
- 删掉父元素的
transform，top立刻恢复正常
排查方法：在 DevTools 的 Styles 面板里搜 transform、filter、will-change，一个都不能漏。
移动端缩放时 top 百分比突然“跑偏”
用户 Ctrl+滚轮 或 iOS 捏合缩放时，视口物理尺寸变了，但 CSS 渲染逻辑仍按缩放前的父容器高度计算 top 百分比。结果就是视觉上明显错位，且不触发 resize 事件，JS 无法监听修正。
更稳的替代方案：
- 直接用
top: 30vh替代top: 30%，vh 基于视口，缩放时自动重算 - 需要相对父容器？确保父容器有明确
height，并配合transform: translateY()做微调（translateY(50%)是按自身高度算，稳定得多） - 慎用
top+bottom同时设置——它们会挤压元素高度，行为不可控
最常被忽略的一点：百分比定位不是“看起来像那样”，而是严格绑定在包含块的渲染快照上；一旦那个块的高度没被显式锚定，或被 transform 类属性悄悄替换，偏差就不再是“误差”，而是必然结果。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
