Normalize.css 更优，因其校准而非清零默认样式，保留语义化标签支持与有用行为，仅修复浏览器差异；需最早引入、避免全局重置覆盖，并非所有场景都适用。
为什么直接用 reset.css 反而让样式更难调
多数人以为重置就是“清空所有默认样式”，但 reset.css（比如 Eric Meyer 版）会把 margin、padding、font-size 全设为 0，连 button 和 input 的默认内边距、行高都干掉。结果是：表单控件塌陷、列表项缩进消失、标题字号归零——你得手动补一堆基础样式，反而增加维护成本。
Normalize.css 不是“清零”，而是“校准”：保留有用的默认行为（比如 audio 标签的播放控件、sub/sup 的垂直对齐），只修正浏览器间不一致的部分（如 h1 在 IE 和 Chrome 中的 margin 差异、textarea 的可缩放行为）。
- 它修复的是真实存在的渲染差异，不是拍脑袋删样式
- 对语义化标签（
article、nav、time）有明确支持，老浏览器也能降级处理 - 体积小（压缩后约 3KB），不影响首屏加载
如何正确引入 normalize.css 到项目中
顺序错了，Normalize 就白加——它必须是整个 CSS 加载链里最靠前的那个，否则后面自定义样式可能覆盖了它的修复逻辑。
- 在 HTML 的
中，<link>必须放在所有其他 CSS 文件之前，包括你自己的main.css - 如果是用构建工具（Webpack/Vite），确保
@import 'normalize.css';出现在你主 SCSS/Sass 文件的第一行，且没被@layer或@scope包裹 - 不要用 CDN 引入后再自己写
* { margin: 0; padding: 0; }—— 这会抵消 Normalize 对表单元素的合理留白
示例正确顺序：
立即学习“前端免费学习笔记（深入）”；
<head> <link rel="stylesheet" href="node_modules/normalize.css/normalize.css"> <link rel="stylesheet" href="styles/main.css"> </head>
normalize.css 和你自己写的重置规则能共存吗
能，但必须分层控制：Normalize 负责跨浏览器一致性，你的重置规则只负责设计系统内的统一（比如所有卡片的 border-radius、所有按钮的 cursor）。混在一起写，容易漏掉 Normalize 本已修复的点，又重复覆盖。
- 避免在全局选择器里写
button, input, select, textarea { ... }—— Normalize 已经处理过它们的盒模型和字体继承，你只需微调外观 - 如果真要“重置”某类元素（比如移除所有
a的下划线），用更具体的选择器：.content a { text-decoration: none; }，而不是a { ... } - 注意
prefers-reduced-motion等现代特性，Normalize 不包含这类逻辑，需你自己补充
哪些场景下不该用 normalize.css
它不是银弹。如果你的项目目标是极致轻量（比如嵌入式设备上的管理界面）、或完全基于 Web Components + Shadow DOM、或用 Tailwind 等原子类框架且已通过 @layer base 显式声明了基础样式，那引入 Normalize 可能带来冗余。
- Tailwind 用户：检查是否启用了
preflight（默认开启），它内部已整合了 Normalize 的核心修复，再额外引入会导致重复 - 纯 JS 渲染的 SPA（如 React/Vue），若组件样式全部 scoped 或 CSS-in-JS，Normalize 的全局影响可能被隔离，收益变小
- 老旧内网系统（IE8 及以下）：Normalize 从 v8 开始已放弃 IE8 支持，要用就选 v7.0.0，并确认你没用到 Flexbox 相关修复
真正关键的不是“用不用”，而是“你是否清楚当前项目里哪些样式差异来自浏览器，哪些来自自己写的 CSS”。没理清这点，换十种重置方案都只是反复擦黑板。
