padding-top百分比能撑开容器高度，因其值按父容器宽度计算，如16:9用56.25%，配合relative/absolute布局实现宽高比控制，需包裹容器且不设height。
为什么padding-top百分比能撑开容器高度
因为padding-top和padding-bottom的百分比值，是相对于**父容器宽度**计算的，不是高度。这个反直觉特性，恰恰被用来模拟“宽高比”——比如16:9，就是padding-top: 56.25%（9 ÷ 16 = 0.5625）。只要父容器宽度随屏幕变化，这个内边距就会同比例变化，从而撑出等比高度。
常见错误现象：height: 0没写，或父容器没设width: 100%，导致padding-top算出来是0；或者把padding-top写在视频元素本身上，而不是它的包裹容器里。
- 必须用一个
div包裹video或iframe，样式写在包裹层上 - 包裹层需设
position: relative，内部视频设position: absolute; top: 0; left: 0; width: 100%; height: 100% - 不要给包裹层设
height，靠padding-top撑高
video标签直接设width: 100%为什么不行
单纯设width: 100%和height: auto，在多数情况下确实能保持比例，但有两个硬伤：一是当父容器高度被限制（比如Flex布局中align-items: center）时，height: auto可能被截断；二是某些移动端浏览器（尤其是iOS Safari）对video的object-fit支持不稳定，拉伸变形不触发重绘。
使用场景：需要精确控制宽高比（如嵌入YouTube iframe）、父容器本身没有固定宽高、或要兼容老版微信内置浏览器。
立即学习“前端免费学习笔记（深入）”；
-
video自身不参与布局高度计算，所以必须靠外部容器“占位” - 若用
object-fit: cover，得确保父容器有明确宽高，否则失效 - 安卓WebView对
padding-top百分比支持完好；iOS 10+也没问题，但iOS 9及更早需加min-height兜底
16:9、4:3、1:1这些比例对应的具体padding-top值
数值由「高 ÷ 宽」决定，不是凭感觉填。填错一点，缩放时就能看出明显挤压或留黑边。
- 16:9 →
padding-top: 56.25%（9 ÷ 16） - 4:3 →
padding-top: 75%（3 ÷ 4） - 1:1 →
padding-top: 100% - 21:9（超宽屏）→
padding-top: 42.857%（9 ÷ 21 ≈ 0.42857）
性能影响几乎为零，只是CSS计算；兼容性上，所有现代浏览器都支持，IE8+也支持（但IE8不支持box-sizing: border-box，若加了padding或border需额外处理）。
响应式切换比例时，@media里改padding-top会触发重排吗
会，但只重排该容器及其子元素，代价极小。比起JS监听resize再计算高度，CSS媒体查询更轻量、更可靠。
容易踩的坑：在@media里只改了padding-top，却忘了同步调整内部video的object-fit或width/height，导致内容溢出或居中偏移。
- 不同断点用不同比例时，每个
@media块里都要完整定义包裹层的padding-top - 如果视频源本身分辨率多变（如自适应流），建议统一按最大可能宽高比预留空间，避免反复重排
- 慎用
max-width和padding-top混用——max-width生效后，padding-top仍按父级当前宽度算，可能撑太高
真正麻烦的是视频加载完成前的空白高度是否准确，以及全屏退出后是否恢复原比例——这些得靠video的loadedmetadata事件和webkitendfullscreen等钩子补位，纯CSS搞不定。
