.class 比 div.class 快，因浏览器从右往左解析：前者直接定位，后者需先找所有.class再向上检查父节点是否为div；大量DOM下差异显著。
为什么 .class 比 div.class 快
浏览器从右往左解析 CSS 选择器，div.class 先找所有 .class 元素，再逐个向上检查父节点是否为 div；而 .class 直接定位元素，跳过回溯。实际项目中，这种差异在大量 DOM 节点（如表格行、列表项）下会放大渲染耗时。
- 避免在高频更新区域（如动画容器、虚拟滚动区）使用标签前缀的类选择器
- 用
data-属性代替语义化标签约束，例如用[data-role="button"]替代button.btn - 框架组件内尽量用单一类名，Vue/React 的 scoped CSS 或 CSS Modules 默认生成唯一类，天然规避层级问题
:nth-child() 和 :nth-of-type() 的性能陷阱
两者都触发重排计算，但 :nth-of-type() 需要遍历兄弟节点类型，比 :nth-child() 多一步类型判断。更关键的是，它们会让浏览器放弃样式计算缓存——只要父容器子节点结构稍有变动（比如 JS 插入一个 span），整组匹配结果都要重新计算。
- 静态场景（如固定表头）可用
:nth-child()+ 显式类名兜底，例如给第 2 行加.row-2类 - 完全避免在
will-change: transform或position: fixed区域使用伪类选择器 - 若必须动态奇偶控制，优先用 JS 切换
.odd/.even类，而非依赖:nth-child(odd)
属性选择器 [type="text"] 的隐性开销
属性选择器无法被 CSS 引擎快速索引，尤其当属性值含特殊字符（如 [data-id="item-123"]）或正则匹配（[href^="https://"]）时，浏览器需对每个候选元素做字符串比对。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 把高频使用的属性选择器转为类名，例如将
input[type="text"]改为.input-text - 避免在全局样式表中写
[style]或[hidden]这类通用属性选择器，它们会强制扫描全部元素 - 如果必须用属性值匹配，确保属性是开发者可控的（如自定义
data-），而非用户输入的title或alt
后代选择器 .parent .child 的层级爆炸风险
每多一层空格，匹配复杂度就指数级上升。浏览器要为每个 .child 实例向上遍历所有祖先，直到找到匹配的 .parent。在 Shadow DOM 或 Web Components 场景下，跨边界查询还会额外触发封装检查。
立即学习“前端免费学习笔记（深入）”；
- 严格限制层级深度，生产环境推荐 ≤ 3 层，例如
.card .header .title可接受，.layout .main .content .article .body p必须拆解 - 用 BEM 命名法替代嵌套，把
.modal .modal__header .modal__title写成.modal__title - 对第三方 UI 库的深层定制，优先用
!important+ 单一类名覆盖，而不是写更长的后代链去提高权重
.modal__title {
font-size: 1.25rem;
line-height: 1.4;
/* 不要用 .modal.is-open .modal__content .modal__title */
}CSS 选择器优化不是追求理论最简，而是让样式系统能稳定复用缓存、避开重排触发点。真正难处理的是那些“看起来没毛病”的组合——比如 section[id] h2[data-loaded]，它同时踩中属性选择器 + 后代选择器 + 伪状态三个慢点，却很容易被忽略。
