fr单位基于网格容器的可用宽度（width减去padding、border）分配剩余空间，先扣除固定尺寸和gap，再按份数比例分配；不处理子项padding，但box-sizing、min-width及外层布局干扰会导致失效。
fr单位根本不“扣除”padding，它只认容器的可用宽度
fr 单位不处理、也不感知子元素的 padding，更不会主动从分配中减去它。真正影响 fr 分配的是**网格容器自身**的盒模型尺寸——尤其是它的 width、padding、border 和 box-sizing 设置。子项的 padding 完全不影响 fr 计算，但若子项设了 min-width 或内容撑开，就会反向压缩其所在轨道。
- 浏览器计算
grid-template-columns: 1fr 2fr时，先取容器的 可用宽度（即width减去padding-left + padding-right + border-left + border-right），再在这个值上做分配 - 如果容器没设
box-sizing: border-box，而你又给它加了padding: 20px和width: 100%，那实际可用宽度就比预期少 40px —— 这不是 fr 的问题，是容器自身尺寸被挤了 - 子项写
padding: 16px不会触发 fr 重算，但它会让内容区变窄；若子项还写了min-width: 300px，而该列 fr 分到的宽度只有 280px，这一列就会溢出或撑破网格
为什么开发者工具里看到的列宽不是整数？
常见现象：两个 1fr 列显示为 399.5px 和 400.5px，看起来不均等。这不是 fr 算错，而是浏览器在像素对齐时做了舍入 —— 尤其当容器总宽是小数（如 799.5px）且存在 gap 时，扣除 gap 后剩余空间无法被整除，最终按浮点精度分配再四舍五入渲染。
- 检查容器的
Computed width是否为整数；非整数宽度 +gap是最常见诱因 -
gap是刚性占位，比如gap: 10px在三列布局中会扣掉 20px，这个值参与所有计算，不是“视觉留白” - 避免混用
px和fr时忽略gap：例如grid-template-columns: 200px 1fr 1fr; gap: 12px→ 实际分配基础是容器可用宽 − 200px − 24px
子项 padding 导致内容溢出怎么办？
子项设置了 padding 又没控制收缩性，长文本或图片会直接撑裂轨道。fr 分配的是轨道宽度，不是内容区宽度 —— 它不保证内容能“刚好装下”。
- 给子项加
min-width: 0和overflow: hidden，防止长单词或 URL 撑开容器 - 避免写
width: 100%：它强制占满轨道，无视padding和gap预留空间 - 若需内边距语义，优先用容器的
padding+gap组合，而非在每个子项上重复设padding
box-sizing: border-box 是 fr 可靠运行的前提
没设 box-sizing: border-box 的网格容器，其 padding 和 border 会额外增加总宽，导致可用于 fr 分配的“可用宽度”小于预期。这比 fr 本身的问题更隐蔽、更常被忽略。
- 全局加
* { box-sizing: border-box; }是最低成本防御手段 - 特别注意外层 flex 容器嵌套 grid 时：flex 项默认
min-width: auto，可能限制 grid 容器宽度，使 fr 失去足够分配空间 - IE11 不支持
box-sizing的某些组合，降级时需用@supports (box-sizing: border-box)包裹 grid 样式
fr 单位的“弹性”完全依赖于容器尺寸的确定性。一旦父级宽度受 margin/padding/border/外层布局干扰而浮动，fr 就只能在不断缩水的剩余空间里挣扎分配 —— 这不是单位缺陷，而是盒模型边界没理清。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
