根本原因是各浏览器用户代理样式表对默认 margin、padding、font-size 等定义不同，导致 h1、button 等元素渲染差异；Normalize.css 通过“收敛”而非“清零”统一有歧义的默认样式，须作为首个样式表引入，且无法解决 gap、focus-visible、aspect-ratio 等新特性兼容问题。
为什么 margin 在 Chrome 和 Firefox 里看起来不一样
根本原因不是浏览器“乱来”，而是各浏览器内置的 user agent stylesheet（用户代理样式表）对元素默认 margin、padding、font-size 的定义不同。比如 h1 在 Safari 默认加了 margin-block-start: 0.67em，而 Firefox 可能是 0.83em；button 的 line-height 和 border 渲染逻辑也存在细微差异。
这些差异在单个元素上不明显，但一旦嵌套、组合或响应式布局时，就会放大成错位、行高塌陷、按钮高度不一致等问题。
- 不要靠手写
* { margin: 0; padding: 0; }—— 它抹掉所有语义化默认行为，反而让fieldset、details等元素失去可访问性基础样式 - 避免只测 Chrome —— Edge（Chromium 内核）和 Safari（WebKit）对
rem基准、flex子项最小尺寸处理仍有分歧 - 注意
Normalize.css不是“清零”，而是“收敛”：保留有用的默认行为（如audio的播放控件、sub/sup的垂直偏移），仅统一有歧义的部分
如何正确引入 Normalize.css 而不覆盖自定义样式
顺序决定一切：Normalize.css 必须作为整个 CSS 加载链的**第一个外部样式表**，且必须放在所有自定义 CSS 文件之前。
错误写法：
<link rel="stylesheet" href="main.css"><br><link rel="stylesheet" href="normalize.css">
这会让
main.css 里的规则被 normalize.css 后续重置覆盖，白忙一场。
- 推荐用 CDN（版本锁定）：
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/normalize/8.0.1/normalize.min.css"> - 如果用构建工具（Vite/Webpack），在入口
main.css或index.scss顶部用@import，且确保它排第一：@import 'normalize.css'; - 不要把
normalize.css内容复制进你自己的 CSS 文件头部 —— 某些构建工具会因 @charset 声明位置异常导致编码解析失败
Normalize.css 解决不了的三类常见兼容问题
它专注 HTML 元素默认样式的收敛，不处理 CSS 新特性兼容、布局引擎差异或 JS 驱动样式。
立即学习“前端免费学习笔记（深入）”；
-
gap在 Flex 布局中仍需-webkit-gap（Safari ≤16.4）——Normalize.css不加前缀 -
:focus-visible行为在 Firefox 和 Chrome 中触发逻辑不同，需额外用focus-visiblepolyfill 或手动降级 -
aspect-ratio在旧版 Edge（EdgeHTML）完全不支持，Normalize.css不做 fallback，得自己写padding-top响应式技巧
比 Normalize.css 更轻量的现代替代方案
如果你项目已用 PostCSS + Autoprefixer，且目标浏览器明确（如只支持 Chrome 110+、Safari 16.4+），可以考虑 modern-normalize。
它删减了对 IE、旧 Android Browser 的适配代码，体积只有 normalize.css 的 1/3，同时保留了 WebKit 对 input[type="search"] 的取消按钮隐藏等关键修复。
- 安装：
npm install modern-normalize - 引入方式相同，但注意它的最新版（v2.0+）默认导出的是 ES module，需确认构建工具支持
- 它不修复
scrollbar-width等非标准属性 —— 这类问题本就不该由 normalize 层解决
真正容易被忽略的是：即使用了 Normalize.css，font-family、line-height、color 等全局继承属性仍需你自己在 html 或 body 上显式声明，否则不同系统字体栈下文字渲染依然会漂移。
