Normalize.css必须在所有自定义CSS之前加载，否则其统一样式会被覆盖而失效；它不是兜底方案而是样式基线，错误顺序会导致button边框残留、h1大小不一、input对齐错位等问题。
Normalize.css必须在所有自定义CSS之前加载
不按这个顺序，Normalize.css 的样式会被后续规则覆盖，失去“重置”意义。它不是用来“兜底”的，而是作为样式基线存在的。
常见错误现象：button 仍有浏览器默认边框、h1 字体大小不一致、input 垂直对齐错位——往往就是加载顺序错了。
- HTML中用
<link>引入时，确保它排在第一个<link rel="stylesheet"> - 如果用了 CSS-in-JS（如 Emotion、Styled Components），需通过
prepend: true或类似机制注入normalize.css的<style></style>标签 - Vite / Webpack 项目里，不要把它 import 到某个组件或 CSS 文件里；应直接在
index.html的顶部引入
别用 CSS Reset 替代 Normalize.css
Normalize.css 不是清空一切，而是统一处理——比如保留有用的 sub/sup 基线偏移、修复移动端点击延迟、标准化表单控件外观。而传统 Reset（如 Eric Meyer’s）会把所有 margin/padding 设为 0，反而增加后续工作量。
使用场景：你希望开箱即用的跨浏览器一致性，而不是从零手调每个元素的盒模型。
立即学习“前端免费学习笔记（深入）”；
-
Normalize.css对语义化标签（article、aside）有合理默认，Reset 通常忽略它们 - 它保留了
strong加粗、em斜体等表现力，Reset 往往一并抹平 - 性能无差异，但维护成本更低：你不用再反复查“为什么这个
hr在 Safari 里多 2px”
如何在现代构建工具中正确接入 Normalize.css
直接下载文件或通过 CDN 都可行，但要注意路径和打包行为。尤其当项目启用 CSS 提取（如 MiniCssExtractPlugin）时，import 位置决定最终输出顺序。
常见错误现象：开发环境正常，生产构建后 normalize.css 被抽离到第二个 CSS 文件，加载晚于主样式。
- Vite：在
index.html的写<link href="/node_modules/normalize.css/normalize.css" rel="stylesheet">（注意路径是否正确） - Webpack：在入口 JS（如
main.js）最顶部写import 'normalize.css/normalize.css';，且确保该 JS 的import语句在任何其他 CSSimport之前 - Next.js：推荐用
pages/_document.tsx中的getInitialProps注入，或使用next/head在_app.tsx中强制前置
要不要自己改 Normalize.css 源码
不建议。它的版本迭代很勤，修改源码会导致升级困难，而且多数定制需求其实可通过后续样式覆盖实现。
容易被忽略的地方：有些团队删掉 Normalize.css 里关于打印样式的部分（@media print），结果在 PDF 导出时布局崩坏——这些规则虽不常显式触发，但确实有用。
- 真要定制，用 PostCSS 插件（如
postcss-normalize）按需启用特性，比手动删更安全 - 若项目完全不用
font标签或marquee，可忽略对应规则；但别动html、body、button等核心重置 - 检查你用的版本：v8+ 已移除 IE 低版本 hack，若还需兼容 IE9，得锁定 v7.x
