全局选择器（如、div、[type]）显著拖慢重绘回流，因样式引擎需遍历大量节点；应避免重置，慎用元素/属性/后代选择器，优先class控制状态，限制层级≤3，全局规则放base.css并降权。
全局选择器会拖慢重绘和回流速度
浏览器在匹配 CSS 时，全局选择器（如 *、div、[type]）会让样式引擎不得不遍历更多节点，尤其在 DOM 深度大或节点数多时，直接拉高样式计算耗时。现代框架（React/Vue）的频繁局部更新，叠加低效选择器，容易让 Recalculate Style 成为性能瓶颈。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 避免用
*做重置，改用html, body, div, p, h1, h2, ...显式列举，或用现代方案如all: unset（注意兼容性） - 慎用元素选择器（如
button），它等价于“所有 button 标签”，一旦页面有 500 个按钮，每次样式变更都要逐个比对 - 用 Chrome DevTools 的
Rendering > Paint flashing和Layers面板观察重绘范围，配合Performance录制看Recalculate Style占比
attribute 选择器在 class 动态切换时容易失效
比如写 [data-status="loading"] 控制按钮状态，但 JS 里用 el.setAttribute('data-status', 'success') 更新后，样式没变——不是选择器问题，而是属性值变更触发了重排，但若同时存在 .btn[data-status] 这类组合，浏览器可能因匹配逻辑延迟而漏掉更新。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先用 class 控制状态：
.btn--loading，而非[data-status="loading"]；class 切换更轻量，且能被 CSSOM 更快索引 - 如果必须用 attribute 选择器，确保属性值是静态字符串，避免用
[data-id]这类无值判断——它会匹配所有含该属性的元素，不管值是什么，匹配开销更大 - 在 Web Components 或 Shadow DOM 场景下，
[attr]无法穿透作用域，容易误以为“写了却没生效”
后代选择器（空格）在嵌套深时放大性能损耗
.modal .header .title 看似清晰，但浏览器是从右往左匹配：先找所有 .title，再向上查是否父级有 .header，再查是否祖父级有 .modal。DOM 越深，回溯路径越长，尤其当 .title 出现在几十个地方时，效率直线下降。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 限制选择器层级 ≤ 3 级，超过就拆成 BEM 式命名：
.modal__title替代.modal .header .title - 避免用
body .content div p这类宽泛路径，它等于“body 下任意深度的 p 标签”，浏览器无法剪枝 - 用
CSS.escape()处理动态生成的选择器时，别拼出.${namespace} .${component} .${part}，应直接合成.${namespace}-${component}-${part}
全局选择器在 CSS-in-JS 和原子化 CSS 中的隐性冲突
像 styled-components 的 css\`*\{box-sizing:border-box\}\` 或 Tailwind 的 @layer base 里重置 *::before，看似方便，但一旦团队里有人在组件内写 div { margin: 0 }，就可能和全局规则产生层叠竞争，导致调试时发现“明明写了却没生效”。这类冲突在构建产物合并后才暴露，本地开发难复现。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 全局重置只放在最外层 CSS 文件（如
base.css），且用:where(*)或:is(*)降低优先级，避免压过组件样式 - 在 PostCSS 中用
postcss-nested写嵌套时，警惕自动生成的.card div—— 它本质仍是后代选择器，不是局部作用域 - 使用
!important的全局规则要加注释说明影响范围，否则后续维护者很难判断某条margin是谁覆盖的
真正卡住性能的往往不是单个 *，而是多个宽松选择器叠加后，在高频更新区域（如列表滚动、表单校验）反复触发全量匹配。上线前用 Lighthouse 的 “Avoid large layout shifts” 和 “Minimize forced synchronous layouts” 两项重点盯一下，比凭经验猜更准。
