直接用 normalize.css 是因为它保留原生语义与可访问性，仅修正浏览器差异；而 * { margin: 0; padding: 0; } 会破坏表单、表格等默认行为。
为什么直接用 normalize.css 而不是自己写 * { margin: 0; padding: 0; }
因为后者会破坏表单控件、表格、列表等元素的原生语义和可访问性表现，比如 <input type="checkbox"> 在某些浏览器里会变小或失焦，<select></select> 下拉箭头消失，<textarea></textarea> 默认内边距归零后难以识别可编辑区域。
真正需要的是“保留合理默认，修正不一致”，而不是暴力清空。所以优先选社区验证过的重置方案：normalize.css 是目前最轻量、兼容性最好、对现代 CSS 特性（如 flex、grid）友好的选择。
- 不要从 CDN 直接 link，下载最新版
normalize.css文件本地引入，避免网络波动或 CDN 域名失效导致样式崩塌 - 必须放在所有自定义 CSS 之前加载，否则重置规则会被后续样式覆盖
- 如果项目已用
postcss-preset-env或类似工具，注意它可能自动注入部分 normalize 行为，重复引入会导致冗余
如何在 Vue/React 项目里正确接入 normalize.css
框架项目常因模块作用域或打包顺序导致重置失效。比如 Vue CLI 默认把 main.js 里 import 的 CSS 放在组件样式之后；React 中用 create-react-app 的 index.css 如果没手动调整顺序，也会被 CSS-in-JS 库（如 Emotion）生成的样式盖掉。
- Vue：在
main.js最顶部 import，且确保它早于app.use(...)和任何全局样式注册 - React：把
normalize.cssimport 放在index.js最前面，比ReactDOM.render和任何主题 Provider 都靠前 - Next.js：在
_app.js的useEffect外部 import，或通过next/head注入 link 标签（但推荐前者，避免 FOUC）
normalize.css 不解决哪些问题？得自己补
它专注修复浏览器间差异，不处理设计系统层面的统一，比如字体栈、链接下划线、按钮焦点轮廓、图片默认 display 等。这些不是“错误”，而是设计决策，必须手动补充。
-
img默认是 inline 元素，容易产生底部空白——加img { display: block; }或vertical-align: middle; -
a没有默认下划线，视觉反馈弱——建议加a { text-decoration: underline; }并配:hover变化 -
button在 Safari 里默认有阴影，Firefox 里圆角不同——需显式设border-radius: 0;和box-shadow: none; - 如果你用 CSS 自定义属性做主题，
normalize.css不会帮你定义--color-primary这类变量，得自己建:root块
用 PostCSS 插件替代手写重置？小心副作用
像 postcss-normalize 这类插件看似方便，但它会把 normalize 规则内联进每个 CSS 文件，导致重复代码膨胀，且无法按需剔除不需要的部分（比如你根本不用 <ruby></ruby>，但它仍会注入相关规则）。
- 构建产物体积增加 2–4KB（gzip 后），对首屏关键 CSS 不友好
- 调试时看到的样式来源是“generated by postcss-normalize”，定位困难
- 升级
normalize.css版本时，必须同步更新插件版本，而插件更新往往滞后 - 更稳妥的做法：用 npm 安装
normalize.css，再通过@import或 import 引入，版本可控、路径明确、调试直观
实际项目里最容易漏的是重置生效范围——比如只在主应用入口加了 normalize.css，但微前端子应用或 iframe 内嵌页完全没处理，结果同一套 UI 在不同容器里渲染效果不一致。这种问题上线后很难复现，得提前约定规范。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
