结论：单一选择器语法无法解决大型项目样式管理问题，需命名约束、作用域隔离与工具卡点三者结合；CSS Modules 实现天然作用域隔离，BEM 规范强化语义边界，工具链（如 stylelint、CI 拦截）保障落地。
直接说结论：靠单一选择器语法解决不了大型项目的样式管理问题，真正有效的做法是用命名约束 + 作用域隔离 + 工具卡点三者组合。
为什么 .btn 这类泛用类名在大型项目里必然失控
不是写法错，而是缺乏约束机制。多个团队、模块同时定义 .btn，没人知道它在哪被覆盖过、谁还依赖它、删掉会不会崩页面。调试时常见现象：!important 泛滥、Chrome DevTools 里样式线反复横穿、hover 效果在某个子路由下突然失效。
- 根本症结是“全局命名空间无管控”，不是选择器写得太长或太短
- ID 选择器（
#header）几乎不能复用，类选择器（.card）又太宽泛，纯靠开发者自觉无法规模化 - 嵌套选择器如
.card .title看似语义清晰，但一旦另一个模块也用.card，就触发隐式耦合
CSS Modules 是最易落地的作用域隔离方案
它不依赖构建配置开关，只靠文件名约定就能生效——必须用 .module.css 后缀，CI 可自动拦截非模块化 CSS 提交。
- 写法上强制
import styles from './Button.module.css'，所有 class 都变成哈希名（如Button_button__kSd2a），天然避免冲突 - 动态拼接 class 必须走
styles.button，禁用字符串模板`btn ${isPrimary ? 'primary' : ''}`，否则破坏作用域 - 对接旧代码只能用
:global(.legacy-header)，且需加注释说明迁移计划，不可滥用
BEM 命名不是万能，但能卡住选择器深度和语义边界
BEM 不解决作用域，但它让“谁属于谁”变得可读、可校验、可自动化拦截。
立即学习“前端免费学习笔记（深入）”；
- 允许：
.card__title、.card--featured；禁止：.card .title、.card > h2、.card__title.is-active（应写成.card__title--active） - 所有 BEM 类名必须通过
stylelint-selector-bem-pattern校验，CI 失败即阻断提交 - Modifier 不叠加使用，
button--primary button--large可以，button--primary--large违反规范，语义模糊且难维护
:nth-child() 和 :not() 在列表页里是性能隐形杀手
看似简洁的选择器，在 DOM 节点超 500 行时会明显拖慢 FPS，浏览器需遍历全部兄弟节点计算索引。
- 替代方案：服务端或 JS 渲染时直接注入
class="row-odd"，CSS 只写.row-odd - 禁用
div:not(.disabled):not(.hidden)这类嵌套:not()，现代浏览器优化有限，复杂度指数级上升 - 滚动区域用
will-change: transform隔离，避免重排触发全量选择器匹配
真正难的不是写出一个正确的 .card__title--hover，而是在新增一个 .input 类时，整个团队下意识检查它是否已在 17 个模块中存在同名但样式冲突的定义——这靠文档没用，得靠工具链在提交前就卡住。
