根本原因是各浏览器用户代理样式表对margin、padding、font-size等默认值定义不同，导致h1、button等渲染差异；应引入normalize.css收敛而非清零，默认样式须作为首个样式表加载，并避免calc单位缺失、gap简写及色彩空间隐性兼容问题。
不是你的 CSS 写错了，是 Chrome（Blink）和 Firefox（Gecko）对同一段代码的解析逻辑、默认行为、容错策略根本不同——直接修代码比等浏览器对齐快得多。
为什么 margin、button、h1 在两个浏览器里看起来不一样
根本原因是浏览器自带的 user agent stylesheet 对这些元素的默认 margin、padding、font-size、line-height 定义不一致。比如：
- Safari 给
h1设的是margin-block-start: 0.67em，Firefox 可能是0.83em -
button在 Safari 默认带圆角和特定line-height，Chrome 是直角+更紧凑的行高 - 这些差异单看不明显，但嵌套进
flex或grid后，立刻导致错位、高度塌陷、按钮对不齐
别用 * { margin: 0; padding: 0; } 粗暴清零——它会破坏 fieldset、details 等语义化元素的可访问性样式。正确做法是把 normalize.css 作为第一个样式表引入，它只“收敛”有歧义的部分，保留有用默认行为。
为什么 gap 在 Firefox 里生效、在 Safari ≤14.0 里没反应
gap 看似简单，但老版本 Safari 和旧 Edge 的解析逻辑不统一：
- Safari ≤14.0 只认分开写的
row-gap和column-gap，gap: 12px 8px这种双值简写会被完全忽略 - Edge 16–18 虽标称支持
gap，但实测存在文字底部被截断、垂直居中偏移等渲染偏差 - 稳妥写法是显式声明：
row-gap: 12px; column-gap: 12px;，而不是依赖gap简写
postcss-gap-properties 可以帮你补全语法，但它不能修复 Safari 渲染层的问题，仅解决写法层面。
为什么 calc(100% - 20) 在 Firefox 报错、Chrome 却“好像能跑”
calc() 内部单位缺失是典型隐性雷：
-
calc(100% - 20)在 Firefox 直接失效（报解析错误），Chrome 可能悄悄补px或静默忽略——这种“宽容”反而让问题延迟暴露 - 所有数值必须带单位：
calc(100% - 20px)才安全；禁用calc(1em + 1px)这类混合不可运算单位 - 颜色同理：
#FF6B6B在 Safari（倾向display-p3）、Chrome（严格srgb）、Firefox（gamma 校正微差）下实际渲染色相不同，关键品牌色必须用color(srgb 1 0.4196 0.4196)显式声明空间，并前置#FF6B6Bfallback
真正难搞的从来不是写法本身，而是那些“Chrome 跑得通、一上 Firefox 就崩”的隐性依赖：比如 fr 单位要求容器有明确尺寸才能计算，而 Firefox 比 Chrome 更严格检查这一前提。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
