优先用类选择器，标签选择器适合全局复用，id选择器仅限js锚点或唯一容器；id重复导致css/js不可预测，类名重复合法，标签写错则不匹配。
怎么选：标签、类、ID 三种选择器到底用哪个？
看用途，不看“高级感”。div 这种标签选择器适合全局样式复用，比如统一设置所有 p 的行高；.btn 类选择器是主力，组件化开发里几乎全靠它；#header ID 选择器现在基本只用于 JS 锚点或极少数唯一容器，CSS 里慎用——它权重太高，后期难覆盖。
常见错误现象：#nav li a 写成 .nav li a 却发现样式没生效，其实是 HTML 里写的是 id="nav" 而不是 class="nav"；反过来，给多个按钮加 id="submit"，结果样式只对第一个生效（ID 必须唯一），JS 获取也出错。
- 标签选择器：零成本，但太宽泛，
ul li可能误伤嵌套深的菜单 - 类选择器：推荐默认起步，命名别用
.red-text这种描述性名字，改需求时要重写样式 - ID 选择器：CSS 中尽量不用，除非你明确需要比
!important还强的优先级（通常不该有）
权重冲突时，为什么加了 !important 还没用？
因为 ID 选择器本身权重是 100，类是 10，标签是 1。比如 #sidebar .title（100+10=110）和 body .sidebar .title（1+10+10=21）同时存在，后者再加 !important 也赢不了前者——!important 是在同级比较中起作用，跨权重层级时无效。
使用场景：调试阶段临时加 !important 看效果可以，上线前必须删掉，换成更高权重的选择器组合，比如把 .card-title 改成 .card .card-title（10+1=11 → 10+10=20）。
立即学习“前端免费学习笔记（深入）”；
- 权重顺序：内联样式 > ID > 类/属性/伪类 > 标签/伪元素
-
!important不解决根本问题，只掩盖选择器设计缺陷 - 多人协作时，一个
!important很可能被另一个更狠的覆盖，形成“重要力军备竞赛”
类名重复、ID 重复、标签误用，哪些会直接导致样式失效？
只有 ID 重复会导致浏览器行为不可预测：CSS 可能只应用到第一个，JS 的 document.getElementById() 一定只返回第一个，后续逻辑全断。类名重复完全合法，class="active active" 和 class="active" 效果一样；标签名写错（比如把 section 写成 secton）则选择器根本匹配不到元素，样式自然不生效。
性能影响：大量使用标签选择器（如 div p span）会让浏览器从右往左匹配时遍历更多节点，尤其在 DOM 深、量大的页面里，FPS 明显下降。
- ID 重复：HTML 校验失败，CSS/JS 行为不确定，必须修复
- 类名拼错（如
.btn-prmiary）：样式不生效，但无报错，最难排查 - 过度嵌套标签选择器（如
article > header > h1 > span）：维护性差，且可能因 DOM 结构微调就失效
移动端适配时，类选择器和标签选择器谁更稳？
类选择器更稳。因为移动端常依赖 JS 动态加 class（如 .is-collapsed、.theme-dark），而标签结构容易被框架（React/Vue）或 Web Components 封装打乱，div > ul > li > a 在 Shadow DOM 里直接失效。
兼容性影响：IE8 不支持属性选择器（[type="button"]），但支持类和 ID；不过现在连 iOS Safari 都已放弃对纯标签选择器的优化，更倾向缓存类名匹配结果。
- 响应式常用模式：
.btn--small（BEM 命名）比button.small更可靠，后者依赖标签名 + 类名双重约束 - 用 Web Components 或自定义元素时，标签选择器只能作用于自定义标签名本身（如
my-card），内部结构不可见 - 工具链（如 PostCSS）能自动压缩类名，但没法安全压缩标签名——
span压成s会炸
真正卡住人的，往往不是记不住语法，而是没想清楚“这个样式将来会不会被其他模块覆盖”“这个 class 是不是真代表语义，还是只为了某次临时调整”。选选择器，本质是在做未来半年的维护成本预判。
