链式选择器如.header .nav .menu .item a:hover一改就崩，因其将样式逻辑锁死在DOM层级中：任一父级类名变动（如.menu→.navigation）即导致整条规则静默失效；浏览器从右往左匹配，而人脑习惯从左往右理解，加剧调试难度；应改用语义化单类名（如.item-link:hover）或BEM规范（.menu__item-link:hover）解耦结构依赖。
为什么 .header .nav .menu .item a:hover 这类选择器一改就崩
这类链式选择器表面精准，实则把样式逻辑锁死在 DOM 层级里。HTML 中任意一层类名变动（比如 .menu 改成 .navigation），整条规则就静默失效；更隐蔽的是，它会让 DevTools 无法提示“未匹配”，你得手动排查结构是否对得上。浏览器匹配时从右往左找 a:hover，再逐层向上验证父级，人脑却习惯从左往右理解——这种错位让调试成本指数上升。
用单类名替代层级定位，比如把 .card .title 改成 .card__title
关键不是加长名字，而是切断对父容器的隐式依赖。一个 .card__title 的样式不关心它是否在 .section 下、是否被 div 包裹，只声明“这是 card 模块里的标题”。这样做的实际好处包括：
- 删掉任意父级 wrapper，样式照常生效
- 复制到新页面只需保留 class，不用同步 HTML 结构
- 全局搜索
card__title能准确定位所有使用点，不会误中第三方库的.title - 禁止写
.card .card__title——这是 BEM 最容易被忽略的铁律，等于自己又套了一层嵌套
哪些场景还允许短链，但必须控制深度 ≤ 2 层
完全禁用嵌套不现实，但得区分“语义嵌套”和“结构嵌套”。前者表达设计意图，后者只是推导 DOM 路径。可接受的例外包括：
- 主题切换：
.theme-dark .button合理，因为 dark 是全局上下文，不是某块 HTML 的私有属性 - 响应式断点内限定：
@media (max-width: 768px) { .sidebar .menu-item { display: none; } }可接受，但仅限于布局收束，且禁止继续嵌套子元素 - 组件内部强封装：
.modal .modal-body p前提是该.modal是独立交付、不与其他模块共享的 UI 单元
判断标准很直接：删掉某层父元素，样式是否立即错乱？如果会，那它本质仍是结构依赖，得重构。
立即学习“前端免费学习笔记（深入）”；
用 data- 属性和 CSS 自定义属性减少重复声明
当发现反复写 color: #333; margin: 1rem;，问题不在选择器长度，而在声明冗余。更深层的维护负担来自值重复和魔数：
- 用属性选择器替代深链：
[data-role="section-title"]比.container .wrapper .content h2更稳定，DOM 变动不影响匹配 - 提取公共值为自定义属性：
:root { --text-primary: #333; --space-md: 1rem; }，后续用color: var(--text-primary) - 状态类统一前置或后置：
.input--error比.form .input.has-error更易预测，也避免因父容器缺失导致状态丢失
真正难维护的从来不是“用了链”，而是“链的意义模糊 + 无法收敛 + 修改成本高于重写”。重构时最容易被跳过的，其实是 JS 里硬编码的 document.querySelector('.header .nav li') —— 它和 CSS 选择器耦合在一起，却常被遗忘。
