normalize.css是更安全的默认起点，它不粗暴清零，而是修正跨浏览器差异、保留语义化默认样式（如select箭头、textarea缩放手柄），并修复老问题（如ie/edge中img baseline留白），同时保障可访问性与用户预期。
直接用 reset.css 很可能让表单控件失能、文字变小、行高塌陷，不是“没生效”，而是它和现代浏览器行为或你用的 UI 框架冲突了；真正该做的是选对方案、控制加载顺序、避开混用陷阱。
为什么 normalize.css 是更安全的默认起点
它不粗暴清零，而是修正差异：比如统一 button 的 font-size 和 line-height，保留原生 select 下拉箭头、input[type="number"] 微调按钮、textarea 缩放手柄；同时修复老问题，如 img 在 IE/Edge 中的 baseline 对齐留白。这些不是“冗余样式”，是可访问性与用户预期的一部分。
常见错误现象：
- 引入
normalize.css后h1看起来比预期小——可能是某 UI 库（如 Ant Design）自带 reset 行为，覆盖了html { font-size: 100% }，触发 UA fallback 尺寸 -
line-height在构建产物里搜出两套值——说明某依赖悄悄注入了 reset 风格规则，和 normalize 的line-height: 1.15冲突
什么时候才该考虑 reset.css？
仅当项目需要从视觉上彻底归零、且团队有能力为每个基础元素（button、input、label、details 等）重新定义语义化表现时才适用。例如强定制化设计系统、游戏化后台、或嵌入式轻量页面。
实操建议：
- 绝不要全局引入经典
reset.css（如 Eric Meyer 版），尤其在表单密集型项目中 - 如果必须用，至少保留
appearance: none的显式控制，而不是无差别设border: 0; background: transparent - 对
dialog、summary等新元素，reset.css完全不处理，需手动补display: none或cursor: pointer
加载顺序和混用冲突怎么查？
所有重置逻辑必须在框架 CSS（如 Bootstrap、Element Plus、Tailwind）之前生效。否则框架会覆盖重置结果，导致样式“看似没起作用”。
判断依据很简单：
- 检查 HTML 中
<link rel="stylesheet">标签顺序：normalize.css必须排第一 - 在构建工具中确认 import 顺序：
import 'normalize.css'要出现在import 'bootstrap/dist/css/bootstrap.css'之前 - 用 DevTools 的 Styles 面板点开任意元素，看
margin、font-size等属性是否来自normalize.css文件，而不是被后面规则划掉 - 搜索 node_modules：若发现多个包都带
normalize或reset（如某些图标库、组件库），删掉重复引入
自己写轻量重置时，这 4 个属性不能省
真正影响跨浏览器一致性的不是 margin/padding，而是底层渲染逻辑相关的属性。以下是最小可行集：
-
* { box-sizing: border-box }—— 统一盒模型，避免 Safari/Chrome 对input宽度计算差异 -
img { max-width: 100%; height: auto; vertical-align: middle }—— 修复 IE/Edge 默认baseline留白 -
button, input, select, textarea { font-family: inherit; font-size: 100%; line-height: 1.15; margin: 0 }—— 对齐表单控件字体继承与行高 -
html { -webkit-text-size-adjust: 100% }—— 防止 iOS Safari 自动缩放文本
复杂点在于：现代浏览器（Chrome 110+、Safari 15+）已原生支持 :focus-visible、dialog、details，normalize.css v8+ 已移除模拟样式；但若项目还用 v7.x，这些规则就会和原生行为打架——比如点击 summary 不展开。版本错配比样式写错更难排查。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
