CSS选择器越长，后续修改的代价就越高——这已成为前端开发者的普遍共识。长选择器与DOM结构紧密耦合，特异性极高，导致后期覆盖时要么被迫使用!important，要么继续拼接更长的选择器链，本质上不是在维护代码，而是在打补丁。而BEM方法的核心思想是将层级关系“拍平”到类名中：避免使用后代选择器，严格限定属性选择器的范围，用状态类代替复杂的伪类选择器，从而使每个组件的样式保持封闭、易于定位。
在编写选择器之前，请先思考一个重要问题：这条样式究竟应该由谁负责？并非所有能生效的选择器都适合写入代码。例如 .header .na v .menu .item a:hover，看似精准匹配，但只要 .na v 改为 .na vigation，整个选择器链就完全失效。更糟糕的是，它的特异性已经达到 0,0,4,1（四个类名加一个类型选择器），后续想要用 .na v-link--active 覆盖它？要么加上 !important，要么继续延长选择器链，只会让代码越来越混乱。
为何选择器越长，修改成本越高
核心原因很简单：选择器的长度反映了对DOM层级的依赖程度。每增加一层，就等于与DOM结构签订了一份“耦合协议”。一旦结构发生变化，样式就会崩溃。更隐蔽的问题是特异性——长选择器累积的权重会让后续任何修改的成本指数级上升。因此，并非不能使用长选择器，而是需要自问：这种“精准”是真正必要的，还是因为贪图方便？
BEM方法：将层级关系拍平到类名中
BEM不仅是一种命名语法，更是一种解耦策略。它让样式不再依赖DOM结构，而是仅基于类名本身生效。举例说明：
- 错误做法：
.card .card__header .card__title→ 三个类名绑定三层结构，DOM变动时如何调整？ - 正确做法：
.card__title→ 单个类名直接作用于目标元素，DOM结构变化也不受影响。 - 状态使用修饰符：
.card--featured、.input--error，不依赖父容器类来控制。 - 避免将类型选择器与类名组合：
h2.card__title比.card__title多了一层隐式耦合，应去掉类型选择器。
这才是真正的“封闭性”——你想修改卡片标题的样式，只需找到 .card__title 这一个选择器，无需在整个项目中搜索所有包含 card 和 title 的组合。
子选择器 > 与后代选择器空格的正确用法：避免样式意外泄露
.list li 匹配所有后代 li，包括嵌套组件中的元素；而 .list > li 仅匹配直接子元素。一个符号之差，影响范围天壤之别。
- 默认优先使用
>，除非你明确需要穿透多层（例如统一设置全站a链接颜色）。 - 组件级样式必须封闭：
.card > .card__body > p，而不是.card p，否则第三方组件的p元素会被意外染色。 - 打开DevTools的“Computed”面板检查，如果某条样式被意外命中，十有八九是某个过于宽泛的后代选择器在作祟。
属性选择器与伪类的使用规范：不要塞进长选择器链
[type="submit"] 本身没有问题，但一旦混入 div#main section.article ul li a[href^="/blog"]:hover 这样的链条，特异性立刻飙升，调试时根本不知道是哪条规则在覆盖你。
- 限定属性选择器的范围：
button[type="submit"]比input[type="submit"]更精准，同时比[type="submit"]权重更低、更安全。 - 将状态类交由JS切换：
.is-active、.has-error直接写在HTML上，避免使用:not(:disabled)这类复杂逻辑拼凑选择器。 :nth-child()依赖DOM顺序，结构变动就会失效；改用:nth-of-type()或直接添加类名来控制更可靠。
真正困难的并非编写一段可运行的CSS，而是当产品需求提出“深色模式下卡片标题加粗”时，你能否在30秒内精准定位到唯一需要修改的样式规则，而不是在整个项目中搜索所有包含 card 和 title 的选择器。
