list__item__subitem是非法BEM命名，因BEM只允许block__element和block--modifier两级结构，三层下划线错误将元素list__item当作独立Block，违背其无复用性、无语义边界的本质。
为什么 list__item__subitem 是非法命名
BEM 不允许出现三个及以上下划线的类名，list__item__subitem 违反了「元素必须直属于块」这一基本约束。它把 list__item 错误地当成了 Block，但 list__item 本身只是 list 的一个 Element，没有独立语义边界和复用能力。
这种写法会带来实际问题：
- 一旦把
list__item改成list__entry，所有list__item__subitem样式静默失效 -
list__item__subitem无法脱离当前 DOM 结构复用（比如在弹窗或侧边栏里渲染相同结构） - SCSS 中写
&__item { &__subitem { } }会编译出非法类名，且容易误给list__item加 padding，破坏 Element 的纯展示职责
深层列表结构该抽成新 Block 还是用 Modifier
关键判断标准不是“嵌套了几层”，而是“这个 UI 片段是否具备独立功能、可复用、有自己状态逻辑”。
- 如果子列表在用户管理页、搜索结果页、设置面板都出现 → 它就是独立 Block：
sublist或更业务化的user-permission-list - 如果子列表只出现在某个卡片内部，且无交互、无动画、样式完全由父级控制 → 优先用 Modifier：
list__item--has-children或list__item--expanded - 如果子列表需要独立 hover 动效、展开收起状态、键盘导航支持 → 必须拆成 Block：
sublist__item、sublist__toggle
不要为“看起来像嵌套”而强行嵌套命名；BEM 管的是语义，不是 DOM 深度。
多级导航菜单中下拉项怎么命名才不崩
导航菜单里的下拉结构最容易踩坑。错误写法如 nav__item__dropdown、dropdown__menu__submenu 都违反职责分离原则。
-
nav只管布局与语义：提供nav__list、nav__item、nav__link - 所有下拉交互逻辑由独立
dropdownBlock 承担：dropdown__toggle、dropdown__menu、dropdown__item - 二级菜单不是“一级菜单的子元素”，而是另一个
dropdown实例，直接嵌在nav__item内部即可 - 若需差异化样式（比如二级菜单 z-index 更高），加 Modifier：
dropdown--secondary，而非靠父级前缀区分
DOM 结构必须对齐 CSS 假设：确保 dropdown__toggle 和 dropdown__menu 是相邻兄弟节点，或后者是前者的直接子节点，否则 :hover + .dropdown__menu 会断链。
用 BEM 替代嵌套选择器能省多少性能开销
浏览器 CSS 匹配是从右往左进行的。.nav .list .item a 这类 4 层选择器，在低端安卓设备上 style recalc 时间可能比单类名慢 4 倍以上。
- 正确做法：每个视觉单元都分配独立 BEM 类名，如
nav__link、list__item、link--primary - 禁止用标签选择器参与组合：
.nav a、ul li都会触发全量扫描 - 伪类统一挂载到类名上：
nav__link--hovered✅，.nav__link:hover❌（JS 无法切换，且匹配成本高） - 媒体查询内嵌套必须 ≤1 层：
@media (min-width: 768px) { .nav__item { display: flex; } }，不再往下写.nav__item .nav__link
真正难的不是拼出合法类名，而是每次加一层 DOM 时，停下来问一句：这个节点有没有自己的功能边界？能不能被抽出来，在别处复用？答案是肯定的，它就不该挂在父 Block 下。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
