fr单位先扣除固定尺寸（如px、gap、内容最小宽）再按份数分配剩余空间，故1fr≠100%÷列数；例如200px 1fr 2fr中，200px先占位，剩余空间按1:2切分。
fr单位怎么算，为什么1fr ≠ 100% ÷ 列数
浏览器计算 grid-template-columns 时，先扣除所有固定占用（比如 200px 列、gap、子项 min-content 宽度），再把剩下的空间按 fr 比例分。例如 grid-template-columns: 200px 1fr 2fr：200px 先占位，剩下空间被切成三份，1fr 拿一份，2fr 拿两份。
而 25% 25% 25% 25% 是直接按父容器总宽（含 padding）切四块，一旦某列内容撑开或有 gap，其他列就被压缩，小屏下极易触发横向滚动条。
-
fr不受父容器padding影响；百分比会把padding算进“100%”里 -
fr自动适配gap；百分比列宽不会自动减去gap空间 -
fr与固定单位并存时逻辑清晰；混用1fr 50%会导致浏览器先分 50%，再把剩下 50% 给1fr，结果不可控
grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)) 为什么比媒体查询更稳
硬写 @media (max-width: 768px) { grid-template-columns: 2fr 1fr } 本质是靠人猜断点，设备宽度微调几像素就可能卡在“差一列挤不进、多一列留白”的临界状态。
repeat(auto-fit, minmax(300px, 1fr)) 让浏览器自己决定能放几列：每列至少 300px，最多吃掉所有剩余空间，列数随容器宽度连续变化，没有卡顿感。
立即学习“前端免费学习笔记（深入）”；
- 媒体查询断点是离散的，
auto-fit+minmax()是连续响应 - 同一行内不同列宽差异大时（如图文混合卡片），
minmax(300px, 1fr)能保最小、撑上限，%只能保比例、无法防坍缩 - 旧版 Safari 对
auto-fit支持弱，可降级为auto-fill，但需配合justify-content: center防溢出
fr在grid-template-rows里失效的三个常见原因
1fr 在 grid-template-rows 里表现异常，90% 的情况不是 fr 写错了，而是网格容器本身没有可参照的高度。
- 父容器设了
height: 300px，子网格必须显式设height: 100%或height: 300px，否则1fr无从计算 -
height: 100vh或height: 100%生效的前提是所有祖先元素（包括html、body）都有明确高度，否则链路断掉，100%变成auto - 用
align-items: stretch（默认值）不能替代高度约束——它只拉伸内容盒，不创造可用空间
混用fr和%时为什么顺序很重要
浏览器按声明顺序逐个解析轨道尺寸：% 列先按容器总宽算出绝对值，剩下的空间才交给 fr 分配。fr 不会回退去压缩前面的 % 列。
例如 grid-template-columns: 50% 1fr 1fr：第一列占 50%（如 500px），剩下 500px 由两个 1fr 平分，各 250px；而 grid-template-columns: 1fr 50% 1fr 还是先算中间 50%（500px），再把剩下 500px 分给前后两个 1fr，各 250px，中间列反而最宽。
- 想让
%列“被挤压”，得用minmax(0, 50%) 1fr，但要注意minmax(0, 50%)在某些旧浏览器中不被支持 -
%在grid-column-start/end中完全无效，写grid-column: 1 / 50%会被忽略 - 真正需要比例+弹性的场景，只在
minmax()内部协作，如minmax(20%, 1fr)，但窄屏下 20% 可能大于容器宽，导致轨道坍缩
fr 的可靠性不来自“更强大”，而来自它只对明确的剩余空间做分配。一旦容器高度未定义、gap 和 border 未纳入计算预期、或混用单位时没理清执行顺序，它就立刻暴露问题——这恰恰是它比百分比更值得依赖的地方：错不了，但必须写对位置、对上下文、对约束条件。
