<p>Normalize.css 必须置于所有自定义 CSS 之前，配合 * { box-sizing: border-box; } 使用，且不可与 reset.css 混用；否则将导致样式失效、FOUC、表单控件异常等问题。</p>
Normalize.css 不是“加了就统一”，顺序错、混用 reset、漏掉 box-sizing，三者任一都会让效果归零。
normalize.css 必须放在所有自定义 CSS 之前加载
它的修复逻辑靠 specificity 和声明顺序生效。比如 button { margin: 0.5em; } 这类规则，只有在你自己的 .btn { margin: 1em; } 之前声明，才能被后者覆盖；如果反过来，你的按钮外边距就永远是 0.5em。
常见错误现象：
- 页面首次渲染时闪一下（FOUC），先按浏览器 UA 样式显示，再重绘
-
textarea在 iOS 上无法拖拽缩放（resize被 UA 样式覆盖后未被 normalize 恢复） -
input[type="number"]的上下箭头在 Chrome 显示、Safari 隐藏（normalize 不干预-webkit-appearance）
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 纯 HTML 项目：用
<link rel="stylesheet" href="css/normalize.min.css">，且该标签必须是<head>中第一个<link> - Webpack/Vite 项目：在主 SCSS 或入口 JS 中写
@import 'normalize.css';，确保它打包后位于输出 CSS 最前面 - 绝对不要把 normalize.css 内容复制进
main.css底部——它的规则依赖前置声明
必须紧接添加 * { box-sizing: border-box; }
normalize.css 修正了 padding、border 的默认表现，但所有元素仍是 content-box。结果就是：你写 width: 100% 的卡片，加了 padding: 16px 后直接撑出父容器。
为什么不用 html, body, div, p, ... 列举？
- 漏：比如忘了
fieldset或details，它们也受 box-sizing 影响 - 冗长：现代浏览器对
*选择器已做深度优化，性能无实质影响
正确写法只有一行，且必须紧跟在 normalize.css 引入之后：
* { box-sizing: border-box; }移动端表单控件仍需手动处理 -webkit-appearance
normalize.css 不会修改 -webkit-appearance，所以这些控件依然保留原生外观：
- iOS
<select>右侧下拉箭头 - iOS
<button>默认灰色背景和圆角 - Chrome
input[type="number"]右侧微调按钮，Safari 默认隐藏
补丁要自己加，且注意可访问性（别直接 outline: none）：
button, input, select, textarea {
-webkit-appearance: none;
}
input[type="number"]::-webkit-inner-spin-button,
input[type="number"]::-webkit-outer-spin-button {
-webkit-appearance: none;
}加完后记得手动补上 border、padding 和 focus 态视觉反馈（例如 box-shadow）。
绝对不能和 reset.css 混用
两者目标相反：reset.css 把 blockquote 的 margin 清零，normalize.css 显式设为 margin: 1em 40px;；混用后谁赢取决于加载顺序和权重，不可预测。
更隐蔽的冲突点：
- 文字突然变小：reset.css 设
html { font-size: 100%; }，normalize 默认不碰这个，混用可能触发 UA fallback 尺寸 - 行高塌陷：某些 reset 方案设
line-height: normal;，直接覆盖 normalize 的line-height: 1.15; - 构建产物里搜到两套
line-height值，说明某 UI 库（如 Ant Design）悄悄自带 reset
判断依据很简单：项目里只允许出现一套“基础样式校准”逻辑。
真正容易被忽略的不是怎么引入，而是它只管默认态——:hover、:focus、:active、伪元素、移动端交互细节，全得你后续一层层补。normalize.css 是起点，不是终点。
