如果页面在 Safari 移动端出现错位、但在 Chrome 中显示正常，通常不是布局“偶发失效”，而是旧版 Safari（iOS 15.4/macOS 12.3 之前）会悄悄忽略 grid-template-areas 这类 CSS 特性：既不报错，也没有任何提示，直接退回到普通流式布局。更稳妥的排查方式，是先通过 Computed 面板确认页面最终的实际渲染结果，再改写为兼容性更强、对 Safari 更友好的写法。
为什么Safari移动端显示错位而Chrome正常
大多数情况下并不是代码写错了，而是旧版 Safari（iOS 15.4 / macOS 12.3 之前）会对部分 CSS 属性和语法进行静默忽略——不报错、不警告，直接回退成默认文档流布局。例如grid-template-areas、grid-column: span 2、repeat(auto-fit, ...)在这些旧版本 Safari 中往往不会真正生效，而 Chrome 移动端对此已经具备稳定支持。
要验证这个问题，不能只凭“页面看起来像错位了”来判断，而要基于真实的计算样式进行排查：
先在 Safari 开发者工具中选中目标元素 → 打开 Computed 面板确认display是否真正为grid → 再到 Styles 面板检查grid-template-columns有没有实际计算值、是否为空 → 最后临时补一条outline: 1px solid red，直接观察子元素是否真的按照网格线对齐。这种方法比单纯看页面效果更准确，也更适合定位 Safari 和 Chrome 显示差异。
Grid布局在旧Safari中怎么写才稳
如果要提升 Safari 兼容性，建议尽量避开那些容易被旧版内核静默丢弃的 Grid 语法，改用更明确、向后兼容性更好的写法：
grid-template-areas: "header main" "footer footer"→ 改为显式定位：header { grid-column: 1 / -1; grid-row: 1; }grid-column: span 2→ 改为grid-column: 1 / 3（起止线编号更稳定可靠，-1在旧版内核中的兼容性通常也更好）repeat(auto-fit, minmax(280px, 1fr)))→ 降级为repeat(2, 1fr)，再结合@media (max-width: 768px)设置为repeat(1, 1fr)row-gap: 16px或column-gap: 16px→ 最好合并写成gap: 16px，因为旧版 Safari 往往只识别这种写法
100vh和dvh在iOS Safari中的坑
当 iOS Safari 中软键盘弹出后内容被遮挡，这通常并不是浏览器 bug，而是因为100vh按照 layout viewport 计算，不会随着 visual viewport 的变化而同步更新。iOS Safari 直到 16.4+ 才开始支持100dvh，但仍有大约 12% 的活跃设备运行在 iOS 15.x，这些设备会完全忽略该声明。
更合适的处理方式：
- 使用
@supports not (height: 100dvh)包裹降级逻辑，回退到height: 100vh+ JS 监听window.innerHeight的方案 - 不要给
或直接设置height: 100vh，否则很容易触发滚动异常；更推荐使用 wrapper div，并设置min-height: 100dvh - 横竖屏切换时如果出现
vw/vh反向计算问题，可通过matchMedia('(orientation: portrait)')监听变化，每次 change 时执行setVH()重设--vh变量，CSS 中写height: calc(var(--vh, 100vh) * 1)（* 1可用于强制重绘）
颜色和transform偏移最容易被忽略的细节
同样的#FF6B6B颜色在 Chrome 里偏橙、在 Safari 里偏粉，原因通常在于 Chrome 默认采用 sRGB，而 Safari（macOS/iOS）默认更偏向 Display P3。另一个常见问题是小数位移，例如translate(0.5px, 0)在 Safari 中经常会被截断为(0, 0)，从而导致 1px 级别的视觉错位。
实操时建议注意以下细节：
- 颜色最好显式声明色彩空间，例如：
color: color(srgb 1 0.4196 0.4196)，并提供 fallback 方案（旧版浏览器会忽略这条声明） transform建议显式补上-webkit-transform，并放在标准声明之前；同时尽量避免小数位移，优先改用整数位移配合scale()或opacity- 父元素上的任何
transform（哪怕是第三方库悄悄添加的translateZ(0)）都可能让子元素的position: absolute以其作为新的包含块——这种偏移往往只会在真机滚动瞬间出现，在 DevTools 中并不容易捕捉
真正棘手的地方，往往不是某一条 CSS 规则写错了，而是旧版 Safari 对标准特性的“选择性执行”：它不会报错，只会默默跳过。因此，排查 Safari 与 Chrome 移动端显示差异时，必须依赖 Computed 面板和真机上的 outline 验证，而不能只依赖桌面模拟器，或凭“看起来差不多”来判断。
