normalize.css通过标准化而非清零解决padding不一致问题，如统一ul、ol为padding-left: 40px并保留语义缩进；必须首个加载以防覆盖，且需配合box-sizing和语义化类名补足表单等场景的padding。
normalize.css 为什么能解决 Padding 不一致问题
不同浏览器对 p、ul、blockquote 等元素的默认 padding 值各不相同（比如 Firefox 给 ul 设 padding-left: 40px，Chrome 可能是 32px），直接靠 * { padding: 0 } 会破坏语义结构。而 normalize.css 不是清零，是把各浏览器的 padding 标准化为一组合理、跨平台一致的值——例如统一设 ul, ol { padding-left: 40px; }，并保留列表符号可点击区域和缩进语义。
引入顺序错会导致 Padding 修复失效
normalize.css 必须是整个样式链中第一个生效的 CSS 文件，否则后续样式会覆盖它的修复逻辑。常见错误包括：
- 在 HTML 中把
normalize.css的<link>放在main.css后面 - 用 Webpack/Vite 构建时，
@import 'normalize.css';写在 SCSS 文件中间或被@layer base包裹 - CDN 引入后又手写
* { padding: 0; margin: 0; }，直接抵消了normalize.css对ul、form等元素的合理padding设置
表单控件的 Padding 异常要单独补
normalize.css 清除了 button、input[type="text"]、select 的浏览器默认 padding，但保留了它们的可访问性基础（如焦点轮廓、热区尺寸）。这意味着你必须显式加回适合设计的 padding：
- 垂直堆叠的表单项建议用类封装：
.form-field { padding: 0.5rem 0.75rem; } - 避免直接改
input { padding: ... }，否则会污染所有输入框（含搜索框、密码框等） - 注意 iOS Safari 对
select下拉箭头的渲染依赖原始padding-right，过小会导致箭头被裁切
调试 Padding 异常时别只看 computed
开发者工具的 Computed 面板显示的是最终值，容易掩盖问题根源。更有效的方式是：
立即学习“前端免费学习笔记（深入）”；
- 选中异常元素，在 Styles 面板里搜索
padding，确认是否被normalize.css显式设置（通常带/* normalize.css v8.x */注释） - 检查该元素父容器是否设置了
box-sizing: border-box，而子元素没继承——这会导致 padding 表现“变少” - 如果用了 CSS-in-JS 或 Shadow DOM，
normalize.css默认不作用于影子树，需手动注入或使用:host规则补充
真正难处理的不是 padding 值本身，而是它和 line-height、font-size、box-sizing 的耦合关系；一旦某处改动触发连锁重排，视觉节奏就容易崩。
