Normalize.css是修复浏览器UA样式差异的标准化工具，确保h1、button等元素在各浏览器中默认表现一致，但不处理伪类、交互态及UA内部渲染逻辑，需手动补充补丁。
Normalize.css 不是重置，是修复浏览器 UA 样式差异
它不把 h1 的字体大小设为 1em，也不让 button 变成透明无边框的文本——而是确保 Chrome、Firefox、Safari 和 Edge 都把 h1 渲染为 2em 加粗，button 都默认有 border、padding、font-family: inherit。这种“求同存异”的逻辑，避免了你后续要手动恢复列表缩进、标题层级、表单可访问性控件（比如 audio 的播放按钮）。
直接引入 CDN 的 @import 会阻塞渲染
别在 CSS 文件顶部写 @import url('https://cdn.jsdelivr.net/npm/normalize.css@8.0.1/normalize.min.css');。这个 @import 是同步加载、阻塞 CSS 解析的，页面白屏时间会变长。更糟的是，某些构建工具（如 Vite 的 CSS 预处理阶段）根本不会处理它，导致最终打包里压根没注入。
- 推荐方式：用包管理器安装，再通过构建流程注入 ——
npm install normalize.css，然后在主 SCSS/JS 入口里写@import 'normalize.css'; - 纯静态项目：下载
normalize.min.css到本地css/目录，用<link rel="stylesheet" href="css/normalize.min.css">，且必须放在所有自定义样式之前 - 绝对不要把它复制粘贴进你的
main.css底部 —— 它的规则依赖 specificity 和顺序，后置会导致:focusoutline 失效、input字体继承异常等问题
用了 Normalize.css 还看到按钮/下拉框样式不一致？正常
因为 Normalize.css 只管“默认态”，不管交互态和 UA 内部渲染逻辑。它让 button 在各浏览器都有 border 和 padding，但不负责消除 Safari 的蓝色 focus ring、Chrome 的灰色 active 背景、iOS 上 select 的原生箭头。
- 必须手动补充轻量修复：比如
button { outline: none; -webkit-appearance: none; } - 移动端还要加
-webkit-tap-highlight-color: transparent;，否则点击高亮遮盖真实样式 -
input[type="number"]的上下微调按钮、search输入框的清除按钮，各浏览器实现完全不同，Normalize.css 明确不覆盖 —— 得靠::-webkit-search-cancel-button等伪元素单独处理 - 千万别和
reset.css混用：两者哲学冲突，h1字号可能被 Normalize.css 设为2em，又被 reset 强制回1em，调试时很难定位源头
PostCSS 插件自动注入 Normalize.css 不可靠
像 postcss-normalize 这类插件，在复杂构建流程中容易失效。它依赖注释标记或特定 @import 语法，而 styled-components、Emotion、甚至某些 Webpack 配置下的 style-loader 会跳过它，导致注入位置错乱 —— 最终生成的 CSS 里，Normalize 规则可能出现在你自定义样式的后面，完全失去作用。
立即学习“前端免费学习笔记（深入）”；
最稳的做法，永远是手动控制：在入口 CSS 或 SCSS 文件最顶部，用完整路径写 @import 'node_modules/normalize.css/normalize.css';（Sass 用户注意加扩展名，避免匹配到其他同名文件），然后检查最终产出的 CSS 文件头部，确认内容确实在最前面。
真正容易被忽略的点，不是“要不要用”，而是“它只修默认态”——所有 hover/focus/active、所有移动端 UA 特有渲染、所有伪元素控件，都得你自己补，而且补的时候还得兼顾可访问性（比如用 box-shadow 替代直接删 outline）。
