应优先选用 normalize.css：它温和校准跨浏览器默认样式差异，保留 h1 语义字号、ul 缩进、button 继承字体等合理默认行为，仅修复真实 bug（如 Safari search appearance、Firefox textarea font-size 继承），避免 reset.css 全盘归零导致的反复补样式和可访问性问题。
normalize.css 是当前新项目的更稳妥选择，尤其在现代浏览器环境（Chrome 110+、Firefox 115+、Safari 16+、Edge 110+）下，它比传统 reset.css 更少引入意外副作用，也更利于维护。
什么时候该直接用 normalize.css？
你正在启动一个面向现代浏览器的新项目，不需支持 IE 或老版 Android WebView，且团队希望减少“重写默认样式”的工作量——比如 h1 保持语义化字号、ul 默认有缩进、button 继承父级字体等行为仍被需要。
-
normalize.css不会清空margin和padding，而是让它们在各浏览器中表现一致（例如所有浏览器下body的margin都是8px） - 它修复了真实存在的 bug：比如
input[type="search"]在 Safari 中的 appearance 异常、img在旧 Edge 中的垂直对齐留白、textarea在 Firefox 中的 font-size 不继承 - 源码带详细注释，每个规则都标明“为什么加”和“修了哪个浏览器的什么问题”，方便团队快速理解或裁剪
哪些场景下 reset.css 反而更麻烦？
当你发现设计师给的 UI 稿里大量依赖浏览器默认排版节奏（如段落间距、列表缩进、表单控件尺寸），而你又用了 YUI Reset 或 Eric Meyer Reset 这类“全盘归零”方案时，很快就会陷入反复补样式的状态。
- 重置后
h2和p字号相同、行高塌陷，必须手动加 typography 基础层 -
ol和ul被设为list-style: none，但设计稿明确要求带圆点/数字，你得再写一遍 - 所有表单控件失去默认 focus outline，可访问性检测直接报错，还得额外加
:focus-visible回填 - 某些 reset 会把
box-sizing强制设为border-box，但如果你项目里已有大量width: 100%+padding的写法，反而导致布局溢出
要不要考虑 Modern-Normalize 或自定义 baseline？
如果你的项目对性能极度敏感（如首屏 FCP 要压到 800ms 内），或者明确只支持 Chromium 内核（如企业内部 Electron 应用），可以跳过 normalize.css，改用更轻量的 modern-normalize（仅 1.5KB gzipped）或手写最小 baseline。
-
modern-normalize移除了对 IE、旧 Safari、Android 4.x 的兼容逻辑，专注修复当前主流内核的已知渲染差异 - 它默认不处理 HTML5 表单类型（如
date、color），因为这些控件在现代浏览器中已基本一致 - 如果你用的是 Tailwind、Windi CSS 等原子化方案，它们内置的
@layer base已隐含类似 normalize 的逻辑，此时再引入完整normalize.css属于冗余叠加
normalize.css，你仍需定期检查它是否与你实际支持的浏览器范围匹配——比如当项目明年开始支持 Safari 18 新特性时，就得确认 normalize.css v8.0.1 是否已覆盖其新增的 user-agent 行为。 
