fr单位无固定像素值，布局时先扣除硬性占用，再按比例分配剩余空间；常见问题包括min-content膨胀、父容器缺尺寸、gap计算误解及混用单位顺序错误。
fr单位的像素值不是预先算好的，而是布局阶段动态得出的
fr 没有固定像素值，它只在浏览器执行自动布局（auto-placement）时，根据当时可用空间实时计算。这个过程分三步：先扣除所有硬性占用（固定宽高、gap、内容最小宽度 min-content），再把剩余空间按比例切分，最后给每份 fr 分配对应像素。所以你用 getComputedStyle 查到的 1fr 值，永远是“那一刻”的结果，不是写死的。
常见错误现象：grid-template-columns: 1fr 1fr 看着该等宽，但第二列明显更宽——往往是因为第一列里有个未折行的长 URL 或 white-space: nowrap 元素，触发了 min-content 膨胀，实际占用了比“1份”更多的初始空间，导致第二列能分到的剩余空间变多。
- 必须确保父容器有明确尺寸（比如
width或max-width），否则无“剩余空间”可分 -
gap会从总宽中整体扣除，不是加在每列后面；例如grid-template-columns: 1fr 1fr; gap: 1rem，两列共享一个 1rem 间隙，不是各加 1rem - 子元素设了
min-width且大于其所在 fr 轨道理论值时，该轨道会被撑开，fr 失效
混合使用 px、%、fr 时，计算顺序决定最终结果
浏览器不会先算 fr 再减 px，而是严格按声明顺序：先满足所有非-fr 轨道的最小约束（包括 px、%、minmax() 的 min 部分、内容自然宽度），再把剩下的空间交给 fr 分配。
例如 grid-template-columns: 200px 1fr 2fr：
总宽 800px → 扣除 200px 和 gap（比如 1rem ≈ 16px）→ 剩余约 584px → 1fr 得约 195px，2fr 得约 389px。
-
1fr和2fr的比例是 1:2，但基数是“扣完之后的剩余”，不是原始容器宽 -
%在 grid 中行为不稳定，不推荐混用；它按容器宽计算，但若容器宽由内容撑开，% 就可能和 fr 冲突 - 写成
minmax(200px, 1fr)时，200px 是硬下限，1fr 是上限——只有当剩余空间 ≥ 200px 时，该轨道才可能伸展到 1fr 对应的像素
为什么有时 1fr 显示为 0px 或远小于预期
表面看 fr “没生效”，大概率是它根本没拿到可分配空间。最常被忽略的三个条件：
- 父容器没设
display: grid，或漏写了grid-template-columns/grid-template-rows—— fr 只在显式网格定义中起作用 - 在
grid-template-rows中用1fr，但父容器高度是auto（比如没设height、min-height或max-height），导致无“可用垂直空间”可分 - 用了
grid-auto-columns: 1fr却忘了grid-template-columns只管显式网格，隐式列默认是auto，不受1fr影响
调试建议：打开浏览器开发者工具的 Layout 面板，勾选“Show grid line numbers”，看是否真生成了预期的网格线；再检查每个轨道的“Track sizing”数值，确认 fr 是否参与了计算。
响应式场景下 fr 的可靠写法：用 auto-fit + minmax() 替代手写 repeat()
直接在媒体查询里改 grid-template-columns: repeat(3, 1fr) → repeat(2, 1fr) 极易出问题：设备宽度微调几像素，就可能卡在“刚好差一点塞下第三列”的临界点，造成布局跳变。
更稳的方式是让浏览器自己判断列数：grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)))。
-
minmax(300px, 1fr)表示每列至少 300px，最多不超过均分所得 -
auto-fit会让空轨道自动收缩，实际列数随容器宽平滑变化 - 注意不要写
minmax(0, 1fr)来防撑爆——虽然有效，但某些旧版 Safari 会误判为无效值；稳妥写法是minmax(min-content, 1fr)或minmax(100px, 1fr)
真正难的是控制内容对轨道的反向挤压。哪怕用了 minmax()，一个没设 word-break 的长单词仍可能撑开整列。这时候 fr 不是失效了，而是它分配的空间，全被内容“吃掉”了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
