通配符重置拖慢样式计算，因其强制浏览器为每个DOM节点执行全量匹配，无法跳过无关元素，5k+节点时开销线性增长；而normalize.css等库通过语义化标签选择器精准匹配，避免全量扫描。
通配符重置为什么让浏览器样式计算变慢
因为 * 选择器强制浏览器为**每个 DOM 节点**执行一次样式匹配，哪怕该节点根本没用到 margin/padding。当页面有 5k+ 元素时，CSSOM 构建阶段的匹配开销会线性增长；而 normalize.css 等库只声明几十条高精度规则（如 h1 { margin-top: 0.67em; }），浏览器可跳过绝大多数节点。
动态操作时的隐性性能惩罚
每次 DOM 变更（innerHTML =、appendChild()、React 组件重渲染）都会触发样式重计算（Recalculate Style）。只要存在 * { margin: 0; }，浏览器就必须重新遍历所有新增/变更节点的祖先链，检查是否命中通配符——这个过程无法被 CSS 引擎有效缓存或剪枝。
- 第三方组件插入弹窗时，哪怕只加一个
div，也会触发整棵子树重匹配 - 暗色模式切换通过 class 切换主题？
*规则仍参与比对，权重虽低但无法跳过 - DevTools 的 Coverage 面板常显示
*规则“100% 已使用”，但它实际只是“100% 被检查”，不等于真正生效
为什么专用重置库能规避这个问题
normalize.css 或 modern-normalize 的每条规则都带明确语义和有限作用域，例如：button, input, select, textarea { margin: 0; }。浏览器只需在遇到这些标签时才检查，其余元素（span、em、time）直接跳过。
- 它们不依赖通配符，避免了「全量扫描」模式
- 关键修复集中于 UA 样式差异大的节点（如
fieldset在 Firefox 有 2px margin，Chrome 没有），而非暴力归零 - 现代写法还会用
:where(*)包裹基础重置，进一步降低选择器权重，减少层叠干扰
接手老项目时怎么判断是不是它拖慢了样式计算
别猜，直接看 Performance 面板里「Layout」和「Recalculate Style」两栏的耗时占比。如果单次 style recalc 超过 8ms，且调用栈频繁出现「StyleEngine::CollectMatchingRules」，大概率是通配符在作祟。
- 临时注释掉
* { margin: 0; padding: 0; }，刷新并对比「Layout」时间变化 - 用 DevTools 的 Elements 面板选中任意
p或ul，在 Computed 标签页搜margin，看是否被划掉——划掉 ≠ 无效，而是被更高权重规则覆盖，说明你还在为它做无谓匹配 - 注意：即使你写了
body { margin: 0; }，只要*还在，性能损耗就仍在
真正卡住项目的往往不是某一行代码多慢，而是它让浏览器在每次 DOM 变动时都多做几千次无意义的“要不要匹配我”的判断——这种开销在静态页面里不明显，一旦接入交互、动画或第三方 SDK，立刻暴露。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
