引入 normalize.css 是为统一浏览器默认样式差异，避免因用户代理样式表导致的布局错位、表单控件不一致等问题，它校准渲染但不改变语义，需正确加载且不可替代 UI 规范。
引入 normalize.css 不是为了“让页面看起来更干净”，而是为了防止你在调试时花两小时排查一个 h2 在 Safari 里比 Chrome 高 3px 的问题——这种差异不是你写的 CSS 导致的，是浏览器自己塞的。
为什么 h1 在 Chrome 和 Firefox 里上下 margin 不一样
这不是 bug，是各浏览器用户代理样式表（User Agent Stylesheet）对同一语义元素的默认实现不同。Chrome 给 h1 设了 margin: 0.67em 0;，Firefox 可能是 0.83em，Safari 又可能加了额外的 line-height 补偿。这些差异叠加到 flex 布局或 grid 中，就会导致对齐错位、卡片高度不一致等真实线上问题。
常见错误现象：
-
textarea在 iOS 上无法拖拽缩放（resize: both被 UA 样式覆盖） -
button在 Edge 里有内阴影，在 Chrome 里没有，导致 hover 效果突兀 -
audio和video默认display值不统一，影响响应式布局流
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 别指望靠
* { margin: 0; padding: 0; }解决——它连button的font-family继承都拦不住 -
normalize.css显式设定了h1 ~ h6的margin-top/margin-bottom比例，且基于现代排版习惯做了微调 - 它不改语义，只校准渲染：保留
h1的加粗和相对字号，只让 margin/line-height 可预测
为什么表单控件在不同浏览器里长得像“失散兄弟”
表单是最容易翻车的区域：input[type="number"] 在 Chrome 显示上下箭头，在 Safari 完全隐藏；select 在 iOS 上下箭头图标位置偏移；checkbox 的 box-sizing 在旧版 IE 里是 border-box，其他浏览器是 content-box。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
normalize.css统一了所有表单元素的box-sizing、font继承、vertical-align和margin基线 - 但它**不处理伪元素**：iOS
select的下拉箭头、Chromeinput[type="number"]的 spinner，仍需你用appearance或自定义背景图覆盖 - 如果你项目里用了
tailwindcss或Bootstrap 5+，它们内部已集成类似逻辑，重复引入normalize.css可能引发选择器权重冲突
normalize.css 加载顺序错了会怎样
它不是“加了就完事”的工具。如果 normalize.css 放在你自己的 main.css 后面，那它的修复规则会被你写的 body { font-size: 16px; } 覆盖——因为 normalize.css 里有更宽泛的 html { font-size: 100%; }，而你的规则优先级更高。
常见错误现象：
- 页面闪一下：先按浏览器默认渲染，再重绘成 normalize 后样式（FOUC）
- 调试时发现
button的padding是 0 —— 其实是你的全局重置规则覆盖了 normalize 对button的padding: 0.375rem 0.75rem;
实操建议：
立即学习“前端免费学习笔记（深入）”；
- HTML 中必须放在所有其他
<link rel="stylesheet">之前 - 构建工具中，确保
import 'normalize.css';出现在入口 JS 或主 SCSS 文件最顶部，且不在@layer base内部 - 绝对不要用
@import在 CSS 文件里引入它——会阻塞后续样式解析
真正容易被忽略的是：normalize.css 只管“同名元素是否表现一致”，不管“设计稿要求 input 必须带 1px #ccc 边框”。它解决的是底层渲染基线问题，不是 UI 规范落地。你依然得写 input { border: 1px solid #ccc; border-radius: 4px; }，只是不用再为“为什么这个 input 在 Firefox 里矮了 2px”查半天。
