vw单位直接用于padding会导致缩放失衡，应配合clamp()限定区间、用CSS变量统一管理，并为不支持的浏览器提供媒体查询降级。
vw单位在padding里直接用会出问题
直接写 padding: 2vw 看似合理，但实际在多数布局中会导致内容区域缩放失衡——因为 vw 基于视口宽度，而 padding 是作用在元素自身的盒模型上，父容器没约束时，子元素的 vw padding 会随窗口拉伸无限放大，尤其在移动端小屏下容易把内容“挤飞”。
- 常见错误现象：
padding: 5vw在桌面端看着正常，切到 iPhone SE（375px 宽）时 padding 只有 ~18.75px，但切到 iPad Pro（1024px）就变成 ~51.2px，视觉节奏完全断裂 - 真正可用的场景是：固定宽高比容器（如卡片、封面图）、或 padding 仅用于视觉留白且不参与布局计算的位置（如 banner 文字区底部留白）
- 注意兼容性：
vw在 IE9+ 支持，但 IE10/11 对vh/vw在 flex 或 table 布局中存在计算偏差，慎用于关键间距
CSS变量 + clamp() 控制padding响应区间
用 clamp() 替代裸 vw，能守住最小值和最大值，避免极端缩放。配合 CSS 变量，方便全局调控。
body {
--pad-base: clamp(0.5rem, 2.5vw, 1.5rem);
}
.card {
padding: var(--pad-base);
}-
clamp(0.5rem, 2.5vw, 1.5rem)意思是：最小 0.5rem，理想值 2.5vw，最大不超过 1.5rem —— 这样在小屏不缩水，在大屏不膨胀 - 别用
100vw当基准：它包含滚动条宽度，导致计算偏大；优先用100%或容器宽度（如max-width: 1200px的 wrapper）做参照更稳 - 如果 padding 需要左右/上下不同，拆成
--pad-x和--pad-y两个变量，避免用clamp()写四值导致可维护性下降
媒体查询 fallback 是必须的
不是所有浏览器都支持 clamp()（IE 全系、旧版 Safari），也不能指望所有项目都能放弃兼容性。CSS 变量本身支持度 OK（IE 不支持），但组合使用时得兜底。
- 写法顺序很重要：先写降级值，再覆盖新语法，浏览器自动忽略不认识的声明
- 示例：
.section {
padding: 1rem; /* IE / 旧 Safari */
padding: clamp(0.75rem, 3vw, 1.25rem); /* 支持 clamp 的浏览器 */
}- 别依赖 JS 检测补丁：CSS 原生 fallback 更轻、更可靠；JS 补丁在 FOUC（闪屏）期间可能露馅
- 如果项目强制支持 IE11，就老老实实用媒体查询分段写，比如
@media (max-width: 768px) { padding: 0.8rem; }
padding-bottom 用 vw 做等比留白要配 height: 0
当需要 padding-bottom 实现「按比例撑开高度」（比如 16:9 的占位容器），单独用 padding-bottom: 56.25% 是经典方案；但换成 vw 时，必须让元素自身高度为 0，否则 padding + height 双重计算会撑爆布局。
立即学习“前端免费学习笔记（深入）”；
- 典型写法：
.aspect-ratio-box {
position: relative;
width: 100%;
height: 0;
padding-bottom: 56.25vw; /* 注意：这里不是 56.25%，而是基于视口的 vw */
}
.aspect-ratio-box > * {
position: absolute;
top: 0; left: 0; right: 0; bottom: 0;
}- 这个技巧只适用于「纯占位、无内容流式撑高」的场景；一旦里面放了文字或 flex 子项，
height: 0会让它们溢出或消失 - 更安全的替代：用
aspect-ratio: 16 / 9（Chrome 88+、Firefox 89+、Safari 15.4+），不用 hack，也不依赖vw
实际项目里最容易被忽略的是：padding 的响应逻辑是否和字体大小、行高、边框一起联动。单改 padding 的响应规则，而 font-size 还是固定值，整体节奏照样脱节。得把 --font-size、--border-width、--pad 统一进同一套 clamp() 或断点体系里才真正可控。
