Chrome 87及更早版本不支持aspect-ratio，会静默忽略该声明；Chrome 88起才原生支持，旧版需用padding-top百分比（基于父宽）配合position:absolute实现兼容，且@supports降级应使用not语法并置于兜底样式之后。
旧版 Chrome（≤87）根本不解析 aspect-ratio，不是报错，是直接丢弃
Chrome 88 才首次原生支持 aspect-ratio，87 及更早版本遇到该声明会静默忽略——DevTools 的 Elements 面板里它会被划掉或根本不显示，Console 里也不会报错。所谓“失效”，其实是浏览器压根没认出这个属性，回退到默认尺寸行为：块级元素高度塌成 0 或由内容撑开，导致布局断裂。
常见错误现象：
- 写了
aspect-ratio: 16 / 9，但容器高度为0或远小于预期 - 构建工具（如 PostCSS + autoprefixer）误删整行——因为
aspect-ratio没有标准前缀，插件常把它当无效声明过滤掉 - 用
@supports (aspect-ratio: 1/1)包裹，结果旧版 Chrome 连@supports都不支持（Chrome 28+ 才支持），整段规则被跳过，降级逻辑根本没执行
padding-top 百分比为什么能从 IE6 兼容到今天
它不依赖新特性，只靠 CSS2.1 就定义的规则：padding-top 的百分比值始终基于**父容器的宽度**计算，而非自身尺寸。比如父宽 400px，padding-top: 56.25% 就等于 225px，自然构成 16:9 的垂直空间。
实操关键点：
立即学习“前端免费学习笔记（深入）”；
- 父容器必须设
position: relative，否则子元素position: absolute会相对于body定位 - 百分比公式固定：
padding-top = (height ÷ width) × 100%，如4:3 → 75%、1:1 → 100%；手算错或写成300px会导致比例失真 - 内容层需
position: absolute; inset: 0（或top: 0; left: 0; width: 100%; height: 100%），否则文字/图片会被 padding 区域“吞掉” - 避免同时写
height: 0和padding-top后又加aspect-ratio——旧版浏览器取height: 0，现代浏览器取后者，反而更难调试
@supports 降级写法必须用 not 判断，且顺序不能反
推荐写法是先写兼容性兜底（所有浏览器都执行），再用 @supports not (aspect-ratio: 1) 包裹现代方案去覆盖。这样 IE 和老 WebView 直接跳过 @supports 块，保留 padding 逻辑；而 Chrome 88+、Firefox 89+ 等会识别并覆盖。
为什么不用 @supports (aspect-ratio: 1/1)？
- 某些老浏览器（如部分安卓 WebView）解析
1/1语法失败，整条@supports规则被丢弃，导致无样式可用 - 不要把
aspect-ratio写在前面、@supports写在后面——层叠顺序会让旧浏览器仍按初始样式渲染，覆盖不干净
@supports not (aspect-ratio: 1) 更稳妥：只要浏览器不认识 aspect-ratio，就进降级分支；认识的话，not (aspect-ratio: 1) 为假，不执行内部样式
Flex/Grid 容器里 aspect-ratio 失效，不是兼容性问题，是布局优先级冲突
aspect-ratio 只在元素有“可推导宽度”时才生效；而 Flex/Grid 的收缩/拉伸逻辑会先锁定尺寸，把比例约束挤掉。
典型场景：
- Flex 子项设了
flex: 1或min-width: 0，触发强制压缩，aspect-ratio形同虚设；临时加flex-shrink: 0可验证是否为此问题 - Grid 列宽写死（如
grid-template-columns: 200px 200px），子项再设aspect-ratio也无效；得改用1fr或minmax(0, 1fr)留弹性空间 - Flex 父容器是
column方向时，子项高度受父容器限制，aspect-ratio只能按宽度反推高度，结果可能小于预期——此时降级到padding-top更可控
最易被忽略的是：哪怕浏览器支持 aspect-ratio，在 Flex/Grid 里它也可能被 layout engine 忽略。别急着换内核，先检查父容器的 display 类型和子项的 flex/grid 属性。
