必须用类选择器而非标签选择器，当需对部分同类型元素差异化样式控制时，如5个p标签中仅2个设为蓝色；类选择器支持跨标签复用、组件化开发、精准作用域及语义化命名，避免标签选择器“一刀切”导致的样式污染与维护困境。
什么时候必须用类选择器而不是标签选择器
当你要给「部分同类型元素」加样式，而不是「所有同类型元素」时，就必须用类选择器。比如页面里有 5 个 p 标签，你只想让其中 2 个变蓝，其余保持默认——用 p{color:blue} 会全部染蓝，根本做不到“挑着改”。
- 需要差异化控制：同一标签类型中，有的要圆角、有的要阴影、有的要禁用状态
- 跨标签复用样式：
<button class="btn">和<a class="btn">都想用同一套按钮样式 - 组件化开发：Vue/React 中每个组件的样式应局部可控，靠标签选择器会污染全局
- 后续可维护性：需求变更时，类名能精准定位作用域，标签选择器一改全崩
标签选择器误用的典型错误现象
写完 input{border:1px solid #ccc} 发现登录框里的 input[type="submit"] 也被套上了边框，但设计稿要求它必须是纯色背景无边框——这就是标签选择器“一刀切”的副作用。更糟的是，后期加 JS 动态控制某几个 input 的禁用状态时，样式和逻辑都得绕着这个全局规则打补丁。
-
ul li a写成全局链接样式，结果面包屑、页脚、侧边栏所有链接都被统一处理，无法单独调整 - 用
h2{font-size:1.5em}统一标题大小，但某个模块的h2实际需要 1.2em，只能靠更高权重选择器或!important强行覆盖 - 调试时发现某段文字颜色不对，查了半天才发现是某个父级的
div p规则在偷偷生效
类选择器命名不等于“多写一个class”
类选择器的价值不在语法上多敲几个点，而在于它把「样式意图」和「HTML 结构」解耦。比如 .form-control 描述的是功能角色，不是视觉表现；换成 .red-text 看似简单，一旦产品说“红色太刺眼，全改成深灰”，你就得全局搜替换所有 red-text，还可能漏掉 error-text、warning-text 这类近义词。
- 命名优先用语义化词：如
.card-header、.nav-item、.is-disabled，而非.big-font或.left-align - 避免纯描述性类名：它们绑定的是“当前长什么样”，而不是“它是什么”，抗需求变更能力极弱
- 多个类名可叠加：
<button class="btn btn-primary is-loading">比写一个巨长的.btn-primary-loading更灵活
ID 选择器不是类选择器的替代方案
看到“这个元素只出现一次”，就下意识用 #user-avatar 而不是 .user-avatar，这是常见误区。ID 选择器权重是 100，类选择器才 10，一旦后面要覆盖它（比如暗色模式下换头像边框），就得写 #user-avatar.theme-dark{...} 或更狠的 !important——而用类选择器的话，.user-avatar.theme-dark 权重刚好 20，干净利落。
立即学习“前端免费学习笔记（深入）”；
- ID 必须唯一，但 HTML 里 ID 重复很常见（尤其 CMS 生成或多人协作时），会导致 CSS/JS 行为不可预测
- ID 选择器基本只该用于 JS 锚点（
href="#section2"）或极少数真正全局唯一的容器（如#app） - 现代框架（React/Vue）中，组件 scoped 样式或 CSS Modules 天然排斥 ID 选择器，强行用反而增加迁移成本
真正难的不是选对选择器，而是从第一行 HTML 就决定好哪些是“角色”、哪些是“装饰”。类选择器不是备选方案，它是默认起点——除非你明确知道自己在批量初始化一组元素的基线样式，且未来绝不会拆分控制。
