aspect-ratio 在旧版 Chrome（Chrome 88 之前）不支持，仅从 Chrome 88+ 开始原生支持，此前版本会静默忽略该属性。
aspect-ratio 在旧版 Chrome（
旧版 Chrome（≤87）根本不认识 aspect-ratio
Chrome 88 才首次原生支持 aspect-ratio，此前所有版本（包括 87、86 甚至 80+）遇到该声明会静默丢弃，控制台无警告、无报错。所谓“报错”，往往是开发者误以为写了就该起作用，结果容器高度塌成 0 或按默认行为撑开，造成布局断裂。
- 检查方法：打开 DevTools → Elements 面板，看
aspect-ratio是否被划掉或完全不显示；再切到 Console，确认没有 CSS 解析错误 - 别信构建工具的“自动补前缀”——
aspect-ratio没有标准前缀，PostCSS 的 autoprefixer 默认不处理它，某些插件反而会误删整行 - 用
@supports (aspect-ratio: 1/1)包裹新写法时，旧版 Chrome 连@supports都不支持（Chrome 28+ 才支持），整块规则会被跳过，降级必须写在外部
padding-top 百分比方案为什么能兼容 IE6 起的所有浏览器
padding-top 百分比值始终基于父容器宽度计算，这是 CSS2.1 就定义的行为，所有浏览器都认。它不依赖任何新特性，只靠三件事：父容器 position: relative、自身 padding-top、内容层 position: absolute。
- 公式固定：
padding-top = (height ÷ width) × 100%，如 16:9 →56.25%，4:3 →75%，手算错会导致比例失真 - 父容器必须设
position: relative，否则absolute子元素会相对于 body 定位，脱离上下文 - 内容层不能只写
width: 100%; height: 100%，得加top: 0; left: 0;或inset: 0，否则可能被 padding 区域“吞掉” - 避免同时写
height: 0和padding-top后又加aspect-ratio——现代浏览器取后者，但旧版因height: 0会压扁内容，反而更糟
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)留弹性空间 - 视频/图片容器务必套一层 div：直接给
<video></video>或<img alt="为什么CSS aspect-ratio属性在旧版Chrome中报错_使用padding-top百分比兼容" >设aspect-ratio无效，它们是替换元素，固有宽高比由资源元数据决定，CSS 不干预
@supports + padding-top 降级写法的实际陷阱
很多人照抄“先 @supports 再 fallback”，结果旧浏览器更糟——因为降级样式没被正确包裹或顺序反了。
- 正确结构：降级样式（
padding-top+position）写在外部、全局生效；@supports块内只写aspect-ratio和配套优化（如overflow: hidden） - 错误写法：把
padding-top放@supports里面，旧浏览器因不支持@supports直接跳过，连降级都没了 - 别混用单位：
aspect-ratio: 16 / 9（带空格）在 Safari 15.3 及更早会失效，必须写成aspect-ratio: 16/9（无空格）才安全 - SSR 或首屏渲染时，
aspect-ratio能在 HTML 解析阶段就预留空间，防止 CLS；而 JS 计算宽高比或监听ResizeObserver都晚于首屏绘制，无法解决布局抖动
最易被忽略的一点：padding-top 方案里，如果内容层有 margin 或未设 box-sizing: border-box，边框和内边距会额外撑高父容器，破坏比例。这不是 aspect-ratio 的问题，是降级方案本身的盒模型细节没控住。
