百分比单位仅以父元素宽度为基准计算，不适用于高度依赖场景；适合width、max-width、margin/padding横向控制；应避免height设百分比而无显式父高、在flex/grid中硬写width、混用vw/vh与%导致冲突。
百分比单位不是万能的响应式方案，用错地方反而让布局更难控制——它只对 width、height（部分场景）、margin、padding、left/right/top/bottom（需配合定位）生效，且所有计算都基于父元素的 width，和父元素高度无关。
百分比的计算基准到底是啥
很多人以为 padding-top: 10% 是按父元素高度算的，其实不是。除 top/bottom 在定位元素中参考父元素高度外，其余所有百分比值（width、height、margin、padding、border-radius）一律以父元素的 width 为基准。
这意味着：
-
height: 50%在没有显式设置父元素高度时通常无效（因为父高是auto，子元素无法计算 50% 的具体像素值） -
padding-bottom: 20%和padding-top: 20%实际像素值相同，都等于父元素宽度的 20% -
border-radius: 50%是按自身宽度算的，不是父元素的
哪些属性适合用百分比，哪些要避开
适合用的场景很明确：需要随容器宽度线性缩放的布局结构。
-
width：卡片、栏位、容器宽度（如.container { width: 90%; }） -
max-width：配合居中，防止单列内容过宽（如max-width: 800px;+width: 100%;） -
margin/padding：横向留白、内边距自适应（注意：垂直方向留白也会随屏幕变宽而变大） -
left/right（配合position: relative/absolute）：水平偏移定位
要避开的典型错误：
- 给
height设百分比却不设父元素高度（结果是 0） - 指望
margin-top: 5%在小屏下“看起来更紧凑”——实际可能比大屏还大（因小屏宽度小，5% 反而更小？不，错！小屏宽度小，5% 就小；但人眼感知是“留白比例没变”，所以视觉上并不紧凑） - 在 Flex/Grid 容器里对子项用
width: 33.333%强控列数——Flex/Grid 本身有更鲁棒的分配机制，硬写百分比反而破坏弹性
百分比和 vw/vh/rem 混用时的常见冲突
百分比和视口单位看似都能响应，但行为逻辑完全不同，混用容易互相覆盖或产生意外缩放。
-
width: 50%+max-width: 400px是安全组合；但width: 50vw+max-width: 400px在超宽屏下可能被截断，且失去父容器约束 -
font-size: 1.2rem是根字号倍数，稳定；而font-size: 2vw会随屏幕宽度剧烈变化，小屏字太小、大屏字太大，需加min/max-font-size限制（但 CSS 原生不支持，得靠 clamp() 或媒体查询） - 用
%做容器，再在里面用rem控字体，是合理分层；但反过来，在rem宽度的容器里再套一层%宽度子元素，就多了一层间接换算，调试困难
移动端适配中百分比的实际陷阱
在移动优先开发中，百分比常被误当作“自动适配”的银弹，但它无法解决设备像素比、缩放、横竖屏切换带来的真实问题。
- iPhone 竖屏
width: 100%是 375px，横屏变成 667px，但内容未必适合拉伸——这时需要@media (orientation: landscape)单独调样式 - 安卓某些浏览器强制缩放页面，导致
100%容器实际渲染宽度超过视口，出现横向滚动条；必须确保<meta name="viewport" content="width=device-width, initial-scale=1">存在且未被覆盖 - 图片用
width: 100%但没设height: auto，会导致拉伸变形；更稳妥的是max-width: 100%; height: auto;
真正棘手的地方不在怎么写百分比，而在于判断它该不该出现——当父容器尺寸不可控、或需要跨维度（宽高联动）响应时，% 就该让位给 aspect-ratio、clamp() 或媒体查询。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
