类选择器写对却没生效，大概率是未匹配目标元素：检查class属性是否真实存在、拼写大小写及连字符是否完全一致；确认dom结构与选择器层级（如空格/＞/＋）吻合；排查语法错误致整条规则静默失效或被高优先级规则覆盖。
类选择器写对了却没生效，大概率不是“写错了”，而是它根本没匹配上目标元素——浏览器解析 CSS 时不会报错，只会静默跳过不匹配的规则。
检查 class 属性是否真实存在且拼写完全一致
HTML 的 class 属性值和 CSS 中的 .classname 必须逐字符一致，包括大小写、连字符、空格位置。
-
class="header-nav"只能被.header-nav匹配，.headerNav或.Header-Nav都无效 -
class="btn primary"是两个独立 class：.btn和.primary；.btn-primary是另一个 class，三者互不等价 - JS 动态插入的元素（如
el.classList.add("active")）要确认执行时机：若在 DOM 渲染前操作，该 class 可能根本没写入 HTML
确认选择器层级与 DOM 结构是否吻合
一个空格、一个 >、一个 +，语义完全不同，但浏览器不会提示错误。
-
.container .item（后代）能匹配<div class="container"><ul><li class="item"></ul></div> -
.container > .item（子元素）则无法匹配上面结构，因为.item不是.container的直接子节点 -
.list li:nth-child(2)按父元素所有子节点顺序计数，不是按li标签个数；若第一个子节点是<h3></h3>，那第二个li实际是:nth-child(3)
排查被更高优先级规则覆盖或整条规则静默失效
DevTools 的 Styles 面板里出现删除线（灰色横线），说明被覆盖；如果压根没出现你的规则，可能是语法错误导致整条被丢弃。
- 漏掉右大括号
}：会导致其后所有规则都不解析，常见于@media块末尾 - 拼错属性名：
backgroud-color: red;中backgroud少了个r，整行声明作废，且不报错 -
!important加在拼错的属性上（如dispay: none !important;）毫无意义——那条声明根本没进解析流程 - ID 选择器（
#header .nav a）比类选择器（.nav-link）权重高得多，后者会被前者轻易覆盖
注意动态渲染、Shadow DOM 和缓存干扰
这些场景下，CSS 规则“写了”不等于“起效”，因为匹配时机或作用域已变化。
- Vue/React 中用
v-if或{condition && <div classname="card">} 渲染的元素，在条件为 <code>false时 DOM 中不存在，自然不参与选择器匹配 - Web Components 内部的
<slot></slot>内容，外部样式默认无法影响；要用::slotted(.item)或:host .inner - 本地开发时改完 CSS 刷新没反应？先按
Ctrl+Shift+R（Windows）或Cmd+Shift+R（macOS）强制重载，排除缓存干扰
最常被忽略的一点：CSS 是静态解析的——它不等 JS 执行、不关心条件逻辑、也不穿透 Shadow DOM 边界。匹配失败往往不是代码问题，而是你写的规则和最终渲染出的真实 DOM 之间，差了一层“看不见的结构落差”。
