aspect-ratio比padding-top更可靠，因其原生支持盒模型，不依赖父宽计算，在flex/absolute等布局中仍能稳定维持宽高比，而padding-top在flex子项中易因父宽为0导致坍缩或失真。
aspect-ratio 为什么比 padding-top 更可靠
因为 padding-top 百分比依赖父容器宽度，而一旦父级是 display: flex 或 position: absolute，它的计算基准就容易丢失或错位；aspect-ratio 是浏览器原生盒模型控制，只要元素有可推导的宽度（比如 width: 100%），就能稳定预留空间，不受布局上下文干扰。
常见错误现象包括：在 Flex 子项里 padding-top: 56.25% 完全不撑高、容器瞬间坍缩、内容溢出不可见区域。这些都不是写错了百分比，而是父容器宽度在 flex 计算中被压缩或未显式声明导致的。
- Flex 场景下，若子项没设
flex-basis或min-width: 0，padding-top的“父宽”可能变成 0 -
aspect-ratio不需要height: 0或position: relative就能工作，语义更干净 - 它对内容天然友好：文字、图片默认流式渲染，不用强制
position: absolute塞满
padding-bottom 方案里 height: 0 是必须的吗
是，但仅限于你用 padding-bottom 撑高 + 内容脱离文档流的组合场景。不加 height: 0，内容本身的高度会叠加在 padding 撑出的空间之上，导致容器总高 = 内容高 + padding 高，比例彻底失真。
不过要注意：IE11 在某些文档模式下对 height: 0 渲染不稳定，有些项目会改用 height: auto 配合 overflow: hidden 来规避，但这要求内容不能超出占位区。
-
height: 0是为了让 padding 成为唯一高度来源 - 如果内容只是背景图或纯色块，甚至可以不要子元素，直接在容器上设
background和overflow: hidden - 给
display: block，否则默认 inline 会在底部留空白间隙
@supports (aspect-ratio: 1/1) 为什么不能写成 not 形式
因为 @supports not (aspect-ratio: 1/1) 在 Chrome ≤27、IE、微信 X5、UC 等环境里根本无法解析——整条规则块会被跳过，降级样式压根不会生效，结果是白屏或布局塌陷。
真正安全的写法是先写通用 fallback（所有浏览器都执行），再用 @supports 包裹新特性覆盖旧逻辑：
.ratio-box {
position: relative;
width: 100%;
padding-top: 56.25%;
}
@supports (aspect-ratio: 16/9) {
.ratio-box {
padding-top: 0;
aspect-ratio: 16/9;
}
}
- 顺序反了（比如先 @supports 后 fallback），旧浏览器可能连 fallback 都不认
- 混写
height: 0和padding-top，旧浏览器会取height: 0，直接压扁内容 - 分数写法
16/9比小数1.777更安全，避免浮点精度误差
aspect-ratio 在 Flex/Grid 中失效的真实原因
不是属性坏了，是宽高推导链断了。aspect-ratio 只在元素有明确宽度来源时才触发高度计算；而 Flex/Grid 的收缩/拉伸逻辑会先锁定尺寸，把比例挤掉。
典型表现：Flex 容器里子项设了 flex: 1 却没设 min-width: 0，宽度被压缩到接近 0，aspect-ratio 失去计算基准；Grid 列轨道写死为 200px，行高无法锚定列宽，比例就断了。
- Flex 场景加
flex-shrink: 0或min-width: 0可验证是否为此问题 - Grid 场景改用
1fr或minmax(0, 1fr)替代固定列宽 - 绝对不要对同一元素同时设
height和aspect-ratio，后者会被忽略 - 视频/图片容器务必套一层 ：直接给
或aspect-ratio基本无效，它们有固有尺寸真正容易被忽略的是：老浏览器连
@supports都不认，降级必须写在外部；而现代浏览器里，aspect-ratio和padding-bottom共存时，顺序错了整个 fallback 就崩——不是“多写点保险”，而是结构本身决定了兼容性边界。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
