padding百分比始终参照父元素content box的宽度计算，与高度无关；在flex子项中则参照自身计算宽度，table-cell中被规范禁止使用。
padding 百分比到底参照谁的宽度
它只看父元素的 width，哪怕父元素是 display: flex 或 position: absolute，只要不是 table-cell 或 inline 元素，padding 的百分比就按父容器的 content box 宽度算——不是 height，不是 max-width，也不是视口宽度。
常见错误现象：padding-top: 50% 在竖向长容器里看起来“不够高”，是因为你误以为它参照父元素高度；实际它仍用父元素 width 计算，哪怕父宽只有 200px，那 padding-top 就是 100px，和高度无关。
- 使用场景：做响应式正方形容器（如封面图）、等宽内边距布局、避免 JS 计算 padding
- 注意
padding-bottom和padding-top同样参照父 width，不是父 height —— 这点和 margin 一致，但和height: 50%完全不同 - 如果父元素 width 是 auto（比如未设宽的 block 元素在文档流中），那它的 width 由内容或最大可用宽度决定，此时百分比 padding 仍有效，但结果可能不如预期
flex 容器里 padding 百分比还靠谱吗
靠谱，但得看 flex 项是否已确定宽度。在 display: flex 的父容器中，子项默认不占满剩余空间（flex: 0 1 auto），它的 width 可能为内容宽，此时 padding: 10% 会很小。
常见错误现象：给 flex 子项设 padding: 10%，结果左右内边距窄得看不见——因为该子项 width 还没撑开，父容器的 width 虽大，但子项计算 padding 时用的是**自身计算出的 width**（不是父的）。
立即学习“前端免费学习笔记（深入）”；
- 解决方法：显式设置子项宽度，例如
flex: 1或width: 100%，再应用百分比 padding - 若用
flex: 1，子项 width 由 flex 布局分配决定，此时百分比 padding 才真正基于“分配到的宽度”计算 - 不要依赖
align-items或justify-content来“推”出 padding 效果——它们不影响 padding 的计算基准
百分比 padding 在 table-cell 里失效了？
不是失效，是规范明确不支持：display: table-cell 元素的 padding 百分比值会被当作 0 处理（浏览器兼容行为一致）。这是 CSS 2.1 规定的例外情况。
常见错误现象：把 td 或设置了 display: table-cell 的 div 加上 padding: 5%，结果毫无反应，开发者反复检查父宽、盒模型，最后发现是 display 类型卡住了。
- 替代方案：改用固定值
padding: 0.5em或padding: 8px；或外层包一层 div，让 div 承担百分比 padding，cell 只负责内容对齐 - 注意
table-row和table元素本身也不支持 padding 百分比，只有table-cell是明确被禁止的 - 这个限制和浏览器无关，Chrome/Firefox/Safari 都遵守，别指望加前缀或 hack 绕过
移动端 rem + 百分比 padding 混用会打架吗
不会直接打架，但容易混淆计算源头。rem 是相对于根字体大小，百分比 padding 是相对于父 width，两者基准完全不同。混用时，你得清楚哪部分要随屏幕缩放，哪部分要随内容密度变化。
常见错误现象：用 html { font-size: 16px } + padding: 2rem 做间距，又在某处切回 padding: 5%，结果小屏下百分比 padding 突然变小，而 rem 保持刚性，视觉节奏断裂。
- 推荐策略：同一组件内统一单位；若必须混用，把百分比留作“横向弹性填充”（如卡片左右留白），rem 用于“纵向节奏控制”（如段落间距、按钮内边距）
- 性能影响几乎为零，但可维护性下降——下次改设计稿时，要分别查两套换算逻辑
- 特别注意 viewport 缩放或用户系统字号放大时，rem 会响应，百分比 padding 不会——这点常被忽略
百分比 padding 看似简单，但它不读父高、不认 table-cell、不随字体缩放，所有“应该这样”的直觉，都得先确认父元素的 width 是否如你所想。
