用padding-top而非padding-bottom或height，因其百分比基于父宽计算，可精准锁定宽高比；height百分比依赖父高，无法固定比例，而直接设height会破坏响应性。
为什么用 padding-top 而不是 padding-bottom 或 height？
因为只有 padding-top（和 padding-bottom）在百分比取值时，是相对于父容器的 宽度 计算的——这正是实现宽高比的关键。而 height: 50% 是相对于父容器高度，无法锁定比例；直接设 height 又会破坏响应性。
常见错误是把 padding-top 写在目标元素自身上，结果它撑开自身、又没预留内容空间，导致内容被挤走或定位错乱。正确做法是用一个包裹容器（aspect-ratio-container）承担 padding，再用绝对定位把内容“塞”进去。
-
padding-top百分比值 = (目标高度 ÷ 目标宽度) × 100，例如 16:9 →padding-top: 56.25% - 包裹容器必须设
position: relative，否则子元素的absolute会向上级找定位上下文 - 内部元素设
position: absolute; top: 0; left: 0; width: 100%; height: 100%，才能填满 padding 撑出的空间
如何让这个固定宽高比的盒子真正居中于视口？
仅靠 padding + absolute 只能保证盒内比例正确，但盒子本身还在文档流顶部左对齐。要居中，得在外层加一层居中逻辑——最稳妥的是给包裹容器加 position: fixed 并手动计算偏移，或者用 Flex 布局控制外层容器。
推荐组合：外层用 body 或全屏容器设 display: flex; align-items: center; justify-content: center，包裹容器设 flex: none 防止被拉伸，内部保持 padding + absolute 结构。
立即学习“前端免费学习笔记（深入）”；
- 避免对包裹容器同时设
position: fixed和margin: auto—— 在非 IE 浏览器中，top/bottom/left/right: 0+margin: auto才能真正居中，但需显式设宽高 - 如果必须用
fixed，优先写top: 50%; left: 50%; transform: translate(-50%, -50%)，兼容性好且不依赖宽高声明 - 注意：若页面有滚动，
fixed定位会脱离滚动流，确认这是你想要的行为
padding-top 方案在现代浏览器里还值得用吗？
值得，但要看场景。aspect-ratio CSS 属性（如 aspect-ratio: 16/9）已获主流支持（Chrome 88+、Firefox 89+、Safari 15.4+），写法更直白。但它不能替代 padding 方案的全部能力：
-
aspect-ratio作用于元素自身，无法像 padding 那样“撑开”父容器高度供其他元素布局参考 - 当需要子元素（比如视频、canvas）严格填满且不拉伸时，padding + absolute 仍是最可控的方式
- IE11 及部分老安卓 WebView 完全不支持
aspect-ratio，仍有兼容需求时，padding 方案仍是事实标准 - 注意 Safari 15.4 之前对
aspect-ratio在flex或grid子项中的支持不稳定，容易出现高度塌陷
实际写的时候最容易漏掉哪一步？
忘了清空包裹容器的 height 或设 height: 0。因为 padding-top 是撑高容器的唯一方式，如果容器自带 height: 200px 这类声明，padding 就成了额外叠加，导致整体高度翻倍。
另一个高频遗漏点：没给内部绝对定位元素设 z-index，当它和兄弟元素重叠时，渲染顺序出问题，看起来像“没居中”或“被遮住了”。
- 包裹容器应设
height: 0或height: auto（但后者在某些 flex 场景下可能失效，height: 0更保险） - 内部元素建议加
z-index: 1，尤其当它覆盖在图片、地图等第三方组件上时 - 调试时可临时加
outline: 1px solid red到包裹容器，看清 padding 是否生效、是否撑开了预期高度
这种方案本质是用 CSS 的副作用达成目的，所以每一步都得“反直觉”地控制，稍一松懈就漏掉关键约束。
