aspect-ratio比padding-top更可靠，因其是原生css宽高比控制，直接按比例缩放内容区域，不受flex/absolute等布局上下文干扰；而padding-top百分比仅依赖父容器宽度，易因父级布局变化失效。
为什么 aspect-ratio 比 padding-top 百分比更可靠
旧方案用 padding-top: 56.25%（16:9）撑高容器，本质是靠父容器宽度触发子元素高度计算，但一旦父级被设为 display: flex 或 position: absolute，padding 百分比就失效——它只相对于父容器宽度，不感知实际渲染尺寸。aspect-ratio 是 CSS 原生宽高比控制，浏览器直接按比例缩放内容区域，不受布局上下文干扰。
注意：iOS Safari 15.4+、Chrome 88+、Firefox 89+ 支持；低于 iOS 15.4 的旧版需降级 fallback。
- 必须配合
width: 100%或明确宽度值，否则aspect-ratio不生效 - 不要在轮播容器上同时写
height，会覆盖aspect-ratio计算结果 - 图片仍需设
width: 100%; height: 100%; object-fit: cover，否则拉伸变形
width: 100vw 和 width: 100% 在轮播容器里差在哪
width: 100% 依赖父容器宽度，如果父级有 padding 或 margin，或被 flex 容器压缩，轮播图可能窄于视口；width: 100vw 强制占满整个视口宽度，绕过所有父级约束——这对全屏轮播是刚需。
但要注意：100vw 包含滚动条宽度（通常 ~17px），在非 iOS 系统上可能造成轻微横向溢出。解决方案：
- 加
overflow-x: hidden到body或轮播父容器 - 用
width: calc(100vw - var(--scrollbar-w, 0px))动态减去（需 JS 检测 scrollbar 宽度） - 更稳妥的做法：用
width: 100%+ 确保根容器无 padding/margin，再用aspect-ratio控制高
移动端 touch 滑动时，transform: translateX() 为何比修改 left 更稳
修改 left 触发 layout + paint，动画卡顿明显；transform: translateX() 只影响合成层，由 GPU 加速，滑动顺滑度提升一个量级。
实操要点：
- 轮播项（
.carousel-item）必须设flex-shrink: 0或width: 100%，否则 flex 布局会压缩它们 - 外层容器加
will-change: transform提前提示浏览器优化（仅在需要高性能时启用） - touchmove 中避免读取
getBoundingClientRect()，改用touches[0].clientX缓存起始位置，减少回流
图片加载后轮播高度塌陷？关键在 object-fit 和尺寸来源
常见现象：轮播容器高度忽大忽小，或图片加载后“跳一下”。根本原因是图片原始尺寸未参与容器高度计算，而 aspect-ratio 又没绑定到图片本身。
解法不是等图片加载完再设高，而是从源头切断不确定性：
- 轮播容器用
aspect-ratio: 3 / 1（按设计稿宽高比），不依赖图片尺寸 - 图片统一设
width: 100%; height: 100%; object-fit: cover，强制填充且不拉伸 - 禁用图片默认
max-width: 100%行为（部分浏览器自带），显式重置img { max-width: none; } - 若需适配不同设备图源，用
srcset+sizes，而非 JS 切换src，避免重绘
最易被忽略的点：轮播容器的父级是否设置了 overflow: hidden。没有它，translateX 超出部分会溢出并撑开页面，导致横向滚动条意外出现——这和 100vw 的溢出是两个独立问题，但表现相似，排查时容易混淆。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
