Normalize.css 本质是温和校准浏览器默认样式差异，而非暴力清零；它保留语义化合理默认（如 button 样式、列表缩进），仅修正跨浏览器不一致渲染（如 audio/video 宽高、sub/sup 对齐、details 折叠等），支持 IE9+，需避免与 reset.css 混用。
Normalize.css 和 reset.css 本质区别在哪
它不是清空样式，而是让不同浏览器对默认元素的渲染趋于一致。reset.css 是暴力归零，Normalize.css 是温和校准——比如 button 的边框、font-size 继承逻辑、margin 在 h1~h6 上的差异，它都保留合理部分，只修正不一致。
常见错误现象：引入 Normalize.css 后发现按钮还是蓝底白字、列表项仍有缩进，就以为“没生效”；其实是它本就不该抹掉这些语义化默认行为。
- 使用场景：新项目起步阶段必须引入，老项目补加需先检查是否已有重置逻辑（比如某些 UI 框架自带 reset）
- 兼容性影响：支持 IE9+，若需 IE8，得用
normalize.css@7.0.0（最后支持 IE8 的版本） - 不要和 reset.css 同时用，否则样式冲突不可预测
如何正确引入 Normalize.css 到项目中
最稳妥的方式是通过 npm install normalize.css 安装，再在主 CSS 入口文件顶部 @import 或 JS 中 import 'normalize.css'。CDN 引入容易被缓存或跨域拦截，且无法参与构建流程。
容易踩的坑：直接下载 normalize.css 文件丢进 css/ 目录，却忘了在打包配置里确保它被优先加载——Webpack/Vite 中顺序错位会导致后续样式覆盖 Normalize 的基础规则。
立即学习“前端免费学习笔记（深入）”；
- 路径必须在所有自定义样式之前，例如：
@import 'node_modules/normalize.css/normalize.css'; - Vite 用户注意：
css.preprocessorOptions不影响@import顺序，靠文件引入顺序控制 - 如果用 PostCSS，别在
postcss.config.js里配autoprefixer去处理 Normalize，它本身已无前缀
哪些样式会被 Normalize.css 主动调整
它重点修正是那些“看起来一样、实际渲染不同”的地方：比如 audio 和 video 在 Safari 和 Chrome 中的默认宽高策略、sub/sup 的垂直对齐、details 的折叠状态表现。不是所有标签都被动过，像 div、span 这类通用容器基本不动。
典型错误：看到 input[type="search"] 被加了 appearance: textfield 就手动删掉，结果在 Safari 下搜索框失去原生圆角和清除按钮。
-
img移除默认vertical-align: baseline，避免行内布局塌陷 -
table设为border-collapse: collapse，统一各浏览器表格边框合并行为 -
pre保留white-space: pre-wrap，但修正了 Firefox 下的换行 bug
定制化裁剪 Normalize.css 的边界在哪
可以删减，但仅限于明确知道某条规则与项目完全无关时。比如纯后台管理系统不用 ruby 标签，可删对应段落；但删掉 button 的 user-select: none 会引发点击反馈异常。
性能上几乎无影响（gzip 后仅 2KB），所以不建议为了“精简”而删——真正影响加载的是你把它放在 HTML 里用 <link> 同步加载，而非通过构建工具内联。
- 别删
html和body的基础设置，它们是后续所有盒模型计算的起点 - 移动端项目慎动
touch-action相关规则，iOS Safari 对其解析敏感 - 如果用了 Tailwind CSS，它的
@layer base已内置 Normalize 行为，重复引入会多出冗余规则
Normalize.css 的复杂点不在怎么用，而在什么时候不该动它——多数人的问题，是过早怀疑它、过早覆盖它、过早删减它。
