百分比 padding 的计算基准始终是父容器宽度，与 grid track 宽度、容器高度或 gap 无关，导致响应式下内边距剧烈跳变、内容区被意外压缩；应改用 aspect-ratio、固定 padding 或 gap 控制留白。
因为百分比 padding 的计算基准是父容器的 宽度，不是高度，也不是它所在的 grid track 宽度；当父容器宽度动态变化（如响应式缩放、flex/grid 容器收缩）时，padding 值剧烈跳变，直接破坏轨道内可用空间分配逻辑。
百分比 padding 的计算基准永远是父容器 width
这是最常被误读的一点：padding-top: 20% 和 padding-bottom: 20% 都按父元素的 width 计算，哪怕父容器高度固定为 100vh，也完全不看 height。这意味着：
- 在窄屏下，
padding-top: 20%可能只有 40px；宽屏下变成 200px，子项内容区被无预警压缩 - Grid track 宽度由
grid-template-columns分配，但子项内部的padding却按整个父容器 width 算——两者基准不一致，浏览器无法对齐“视觉留白”和“轨道边界” - 如果父容器本身是
display: inline-grid或受max-width限制，它的 width 会随内容浮动，padding就更不可控
和 gap 混用时，空间被重复扣除
gap 是刚性占位，从容器总宽中直接减去；而百分比 padding 又基于这个已被 gap 缩减过的 width 再计算一次，形成双重挤压：
- 例如：容器宽 800px，
gap: 20px→ 可用宽度剩 780px；此时padding-top: 10%按 800px 算 = 80px，不是按 780px - 结果是：track 分配按 780px 切分，但子项顶部又硬占 80px，内容区实际可用高度骤降
- 若子项还设了
height: 100%，而容器没显式 height，那这个 100% 就是 0px —— 百分比 padding 成了“压垮骆驼的最后一根稻草”
Grid 子项里用百分比 padding 的替代方案
真需要等比例内边距（比如正方形卡片、封面图留白），优先避开百分比 padding，改用更可控的方式：
- 现代项目：直接在子项上写
aspect-ratio: 16 / 9+padding: 1rem（用固定值，不依赖百分比） - 需兼容老浏览器：用
padding-bottomhack，但必须配合position: relative和绝对定位子元素，且只用于容器自身，别套在 grid item 内部再嵌一层 - 想让文字区域留白均匀？改用
grid-row-gap和grid-column-gap控制轨道间距，子项用padding: 1rem固定值，加box-sizing: border-box - 避免在子项上同时写
width: 100%和百分比padding—— 前者按 track 宽度算，后者按父容器 width 算，两个“100%”根本不是一回事
真正棘手的不是百分比 padding 本身，而是它在 Grid 布局中悄悄绕过了 track 边界、gap 分配、甚至 box-sizing 的约束范围——它只认父容器的 width，其他一概不管。调试时最容易漏掉这点，直到布局在某个断点突然错位两像素才回头翻计算逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
