Normalize.css和CSS Reset该如何选更适合新项目？

应优先选用 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 继承父级字体等行为仍被需要。

1. normalize.css 不会清空 margin 和 padding，而是让它们在各浏览器中表现一致（例如所有浏览器下 body 的 margin 都是 8px）
2. 它修复了真实存在的 bug：比如 input[type="search"] 在 Safari 中的 appearance 异常、img 在旧 Edge 中的垂直对齐留白、textarea 在 Firefox 中的 font-size 不继承
3. 源码带详细注释，每个规则都标明“为什么加”和“修了哪个浏览器的什么问题”，方便团队快速理解或裁剪

哪些场景下 reset.css 反而更麻烦？

当你发现设计师给的 UI 稿里大量依赖浏览器默认排版节奏（如段落间距、列表缩进、表单控件尺寸），而你又用了 YUI Reset 或 Eric Meyer Reset 这类“全盘归零”方案时，很快就会陷入反复补样式的状态。

1. 重置后 h2 和 p 字号相同、行高塌陷，必须手动加 typography 基础层
2. ol 和 ul 被设为 list-style: none，但设计稿明确要求带圆点/数字，你得再写一遍
3. 所有表单控件失去默认 focus outline，可访问性检测直接报错，还得额外加 :focus-visible 回填
4. 某些 reset 会把 box-sizing 强制设为 border-box，但如果你项目里已有大量 width: 100% + padding 的写法，反而导致布局溢出

要不要考虑 Modern-Normalize 或自定义 baseline？

如果你的项目对性能极度敏感（如首屏 FCP 要压到 800ms 内），或者明确只支持 Chromium 内核（如企业内部 Electron 应用），可以跳过 normalize.css，改用更轻量的 modern-normalize（仅 1.5KB gzipped）或手写最小 baseline。

1. modern-normalize 移除了对 IE、旧 Safari、Android 4.x 的兼容逻辑，专注修复当前主流内核的已知渲染差异
2. 它默认不处理 HTML5 表单类型（如 date、color），因为这些控件在现代浏览器中已基本一致
3. 如果你用的是 Tailwind、Windi CSS 等原子化方案，它们内置的 @layer base 已隐含类似 normalize 的逻辑，此时再引入完整 normalize.css 属于冗余叠加

真正容易被忽略的点是：没有“一劳永逸”的基线。哪怕选了 normalize.css，你仍需定期检查它是否与你实际支持的浏览器范围匹配——比如当项目明年开始支持 Safari 18 新特性时，就得确认 normalize.css v8.0.1 是否已覆盖其新增的 user-agent 行为。