必须设 height: 0 是因为 padding-top 百分比基于父宽计算，若不设 height: 0，原有内容高度会与 padding 叠加，导致比例失真；同时需父容器有明确宽度且子元素绝对定位填充。
为什么 padding-top 实现宽高比要设 height: 0
因为 padding-top（或 padding-bottom）的百分比值，是基于父容器的 宽度 计算的——这是 CSS 规范定义的行为。但如果不设 height: 0，元素自身还带默认高度（比如内容撑开、行高影响），那 padding 就会叠加在原有高度上，导致最终容器高度 = 原有高度 + 百分比 padding，比例完全失真。
常见错误现象：padding-top: 56.25% 写了，但容器比预期高一截，视频/图片被压扁或留白异常。
- 必须加
height: 0（或min-height: 0）来“清空”原始高度贡献 - 父容器需有明确宽度（如
width: 100%），否则百分比 padding 无基准 - 子内容要用
position: absolute进入这个占位区，否则会触发重排或溢出
用 Sass 封装 ratio mixin 时，为何不能直接用 $ratio * 100%
Sass 是编译时处理，$ratio: 16/9 → 编译后就是 padding-top: 177.77777778%，看似没问题，但浮点精度误差在老浏览器（尤其是 IE11、部分 Android WebView）里可能引发 1px 错位或裁剪偏差。
更稳妥的做法是用分数形式显式控制精度，或转为整数百分比（四舍五入到小数点后两位）：
- 推荐写法：
@include ratio(16, 9)，内部用#{round(($w / $h) * 10000) / 100}%控制精度 - 避免：
#{16/9 * 100}%—— Sass 不做运行时计算，且不控精度 - 别在 mixin 里尝试读取父容器 width：Sass 没有运行时 DOM 能力，
calc()必须留给 CSS
padding-top vs padding-bottom：选哪个更稳
两者数学等价，但 padding-bottom 是行业事实标准，原因很实际：
-
padding-bottom+height: 0组合在所有支持 CSS2 的浏览器中都稳定生效（包括 IE8+） -
padding-top在某些旧版 Safari（transform 或will-change时 - 若容器内有浮动子元素，
padding-top可能触发意外的清除行为，而padding-bottom更“安静” - 所有主流框架（Bootstrap、Tailwind 的 aspect-ratio polyfill）默认用
padding-bottom
和 aspect-ratio 共存时，为什么 padding 方案会被忽略
现代浏览器遇到同时声明 aspect-ratio 和 padding-bottom 的容器，会优先采用 aspect-ratio，并直接跳过 padding 的布局逻辑——这不是 bug，是规范要求的层叠优先级。
所以降级方案必须用媒体查询或特性检测隔离：
- 不要写：
aspect-ratio: 16/9; padding-bottom: 56.25%同时存在 - 正确写法：用
@supports not (aspect-ratio: 1)包裹 padding 方案 - 或者用 JS 检测支持性，动态加 class（如
.has-aspect-ratio/.no-aspect-ratio），再分别写样式 - 注意：
@supports在 IE 中不支持，需配合 UA 判断或全局 class fallback
实际最易被忽略的一点：padding-based ratio 容器内的子元素如果用了 display: flex 或 display: grid，且未设 align-items: stretch 或 justify-content: stretch，内容会默认居中而非铺满——这会让“自适应”看起来失效，其实只是子布局没跟上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
