Safari中fr宽度异常的根源是“可用空间”计算差异：它将百分比、固定值先转为像素再扣减，受滚动条/缩放/DPR影响导致剩余空间跳变，1fr分配抖动；Chrome/Firefox则将百分比视为硬约束，更稳定。
fr单位在Safari中宽度异常的根源是“可用空间”计算差异
不是fr写错了，也不是Safari故意搞事情——它对fr的解析逻辑和Chrome/Firefox有本质区别。关键在于：Safari（尤其是15.4之前）在处理混合单位（比如minmax(30%, 1fr)或200px 1fr）时，会把百分比、固定值先转成像素再扣减，而这个过程受滚动条出现/消失、缩放、DPR变化影响，导致每次重排时“剩余空间”数值跳变，1fr分到的像素就来回抖动。
Safari中minmax(30%, 1fr)抖动的典型表现与验证方式
你看到两列明明写了minmax(30%, 1fr) minmax(30%, 1fr)，但实际宽度一帧320px、一帧321px、再一帧319px，肉眼可见闪烁或错位。这不是渲染bug，而是Safari按规范走了一条更保守的路径：
- 它先算出容器当前宽度的30%（比如800px → 240px），再把剩下560px交给
1fr - 但滚动条隐藏/显示会让容器宽度从800px变成816px（macOS滚动条占16px），30%立刻变成244.8px，
1fr分到的空间就突变 - Chrome/Firefox则把
30%当作硬约束，1fr只管“扣完30%后剩下的”，所以更稳
用开发者工具反复刷新并观察Computed width是否随滚动/缩放跳变，就能确认是不是这个原因。
真正有效的Safari兼容写法
别指望靠加will-change: transform或backface-visibility: hidden压住抖动——那是掩耳盗铃。要改的是轨道定义本身：
立即学习“前端免费学习笔记（深入）”；
- 纯
fr没问题：grid-template-columns: 1fr 1fr在所有Safari版本都稳定 - 需要最小宽度？用
minmax(200px, 1fr)，别混%：minmax(200px, 1fr) minmax(200px, 1fr) - 必须保留百分比语义？降级为
50% 50%，但前提是父容器width严格固定（不能是max-width或fit-content）且总和=100% - 侧边栏+内容区？写成
grid-template-columns: 200px minmax(0, 1fr)，minmax(0, 1fr)在Safari 14.1+已稳定支持
容易被忽略的嵌套陷阱
你以为修复了顶层Grid就万事大吉？Safari里子Grid的fr照样抖——尤其当它被包裹在Flex容器、position: absolute元素或Shadow DOM里时，父级尺寸测量误差会被放大。
检查点：
- 父容器是否用了
display: flex且没设flex-shrink: 0？它可能偷偷压缩Grid宽度 - 子Grid是否在
iframe或Web Component内？那些地方的样式完全隔离，box-sizing: border-box得单独再声明一遍 - 有没有第三方UI库注入了
::before/::after伪元素？它们默认走content-box，多占的像素在Safari里更容易暴露
最麻烦的不是写不对，而是抖动只在特定设备、特定DPR、特定缩放比例下才出现——上线前务必用真机+Safari调试器连上Mac反复拖动滚动条测。
