fr单位计算基准是容器padding-box宽度（content+padding），扣除gap但不扣border/margin；box-sizing: border-box缺失会导致容器“变胖”；gap与子项padding叠加影响视觉密度；子项padding增大min-content间接破坏fr分配。
fr单位计算时是否包含padding-box？
fr单位的计算基准是容器的padding-box宽度（即content + padding），不扣除border和margin，但会整体减去gap。这意味着：如果你给Grid容器加了padding: 20px，那1fr 1fr分的是「总宽 − 左右padding − gap」后的剩余空间；而padding本身不参与分配，只是压缩了可用区域。很多“计算不准”的错觉，其实是误以为fr在border-box或content-box里算。
box-sizing: border-box没生效导致视觉偏差
当容器设了padding但没配box-sizing: border-box，它的实际宽度会超出预期（比如width: 100% + padding: 20px → 总宽 = 100% + 40px），此时fr分的空间比你想象中更小，列宽被压窄，内容溢出或换行。这不是fr算错了，而是容器自己“变胖”了。
- 必须全局或显式设置
box-sizing: border-box，尤其对Grid容器 - 检查Computed面板里的
width值，确认是否真等于你期望的可用宽度 - 若用
max-width约束容器，也要确保它和padding共存时不超限
gap和padding叠加造成间距混乱
gap是轨道之间的空隙，独立于padding；但人眼容易把「项内padding」和「项间gap」混成一种“间距”，结果调大gap后发现卡片看起来太松，调小又觉得拥挤——其实是因为两者叠加放大了视觉距离。
-
gap: 16px+.item { padding: 16px }→ 相邻卡片内容边缘实际相距48px（16 + 16 + 16） - 想控制视觉密度，优先调
gap，再微调padding；别靠猜 - 用开发者工具的Layout视图，直接看grid track和item box的边界，比肉眼判断准得多
子项padding影响min-content，间接破坏fr分配
即使容器尺寸正确，子项自身的padding也会增大其min-content宽度（尤其是配合white-space: nowrap或长单词时）。浏览器先按min-content撑开轨道，再用fr分剩余空间——于是某列被pad得过宽，其他列就被挤瘦。
- 典型表现：
1fr 1fr中一列明显更宽，且该列子项有大padding或未设max-width - 解决不是去掉padding，而是加
min-width: 0+grid-template-columns: minmax(0, 1fr) - 如果子项内部还有flex/grid，它的直系子元素也得加
min-width: 0，否则锁死传导
真正容易被忽略的是：padding本身不干扰fr计算逻辑，但它通过改变容器可用宽度、子项min-content、以及人眼对“间距”的感知，三路同时施压——修bug时得同步盯住这三处，只调其中一项，问题大概率还在。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
