类型选择器复用性差在于强绑定标签语义，导致无法按功能或上下文灵活调整样式，易引发权重膨胀与维护困难；类选择器则通过意图驱动的命名（如.text-sm、.is-disabled）实现跨标签、跨结构的真正复用。
因为类型选择器（如 p、div）绑定的是 HTML 标签语义，而一个标签往往承担多种角色；类选择器（如 .btn、.card）绑定的是功能或视觉意图，天然支持跨标签复用。
类型选择器的复用性差在哪儿？
它不是“不能复用”，而是“不该复用”——一旦你写 p { margin: 1em 0; }，这条规则就强绑定了所有 p 元素。但现实中：
- 有些
p是正文段落，需要默认样式 - 有些
p是按钮内的辅助文字（<p class="btn-label"></p>），其实不该有上下边距 - 有些
p在卡片标题区，需要font-size: 0.9em，和正文冲突
你只能不断加更具体的选择器去“打补丁”，比如 .card p { margin: 0; }，结果就是权重膨胀、维护成本飙升。
类选择器为什么能真正复用？
它不依赖结构，只依赖语义意图。比如：
立即学习“前端免费学习笔记（深入）”；
-
.text-sm可以加在span、p、li、甚至button上 -
.is-disabled可用于button、input、a，统一灰掉+禁用交互 -
.sr-only（仅屏幕阅读器可见）可套在任意元素上，无需关心标签名
这种复用不靠 DOM 层级，也不靠标签共性，靠的是开发者对“这个元素要干什么”的共识。
容易踩的坑：以为“多写几个类”就等于复用
以下做法看似用了类，实则丧失复用性：
- 命名含标签名：
.p-title或.div-wrapper—— 换个标签就得重命名 - 命名含位置：
.header-link、.sidebar-item—— 移到 footer 就失效 - 命名含样式值：
.red-text、.flex-row—— 改设计时全得改 class，HTML 也得批量替换
真正可复用的类名，描述的是“它是什么”，而不是“它长什么样”或“它在哪儿”，比如 .error-message、.nav-link、.price-tag。
复用性不是写一次就能用多次，而是写一次，换场景、换标签、换上下文，依然语义清晰、行为可控。类型选择器从根子上就缺这个弹性。
