padding不参与fr计算，因fr仅基于容器净可用宽度（clientwidth减gap及容器border/padding）分配，子项padding只影响自身内容区大小；列宽不均常因box-sizing未统一或内容溢出所致。
padding 不参与 fr 单位计算，是因为它属于子项自身的盒模型内部消耗，而 fr 只在网格容器的可用空间中做比例分配——两者根本不在同一计算层。
fr 单位只认容器级“净可用宽度”
浏览器计算 1fr 1fr 时，第一步是算出容器的“可用于分配的宽度”：即 container.clientWidth − (所有 gap 总和) − (容器自身的 border + padding)。这个值才是 fr 分配的基数。
子项的 padding 完全不在这一步里出现——它连容器的计算边界都碰不到。
- 子项
padding只影响它自己在轨道内的内容区大小（受box-sizing控制） - 如果子项
align-self: stretch（默认），它的实际渲染宽度 = 轨道净宽 − 自身padding-left − padding-right − border-left-width − border-right-width - 换句话说：
padding是“挤内容”，不是“抢空间”
为什么你看到列宽不均？大概率是 padding 在捣鬼
常见错觉：“我设了 padding: 16px，但两列看起来一宽一窄”。这不是 fr 算错了，而是子项因内容不同导致 min-width 触发，或 box-sizing 没统一，让 padding 实际占位不一致。
- 没加
* { box-sizing: border-box; }→ 子项用content-box，padding会额外撑大总宽，可能溢出轨道 - 子项含长单词或 URL，又没设
min-width: 0; overflow: hidden→ 内容强行撑开，破坏 fr 均分视觉 - 父容器有
padding但没被box-sizing: border-box覆盖 → 它偷偷吃掉了 fr 的分配基数
想让 padding “参与布局感”，得换思路
别指望靠子项 padding 来控制列间距或留白节奏。真正可控、可预测的方式只有两种：
- 用容器级
gap：它直接从 fr 计算基数中扣除，效果稳定、语义清晰 - 把 padding “上提”到网格容器上：比如给
grid-container加padding: 16px，再配合box-sizing: border-box，这样留白就是布局的一部分，不影响子项尺寸逻辑 - 若必须用子项 padding 做内边距，请确保所有子项
box-sizing: border-box+width: 100%（注意：此时width: 100%指轨道净宽，不是容器宽）
最容易被忽略的一点：gap 和子项 padding 解决的是完全不同的问题——前者管“格子之间”，后者管“格子里面”。混用却不加约束，就是布局失准的起点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
