BEM类名结构提升IDE补全精度，因其强制统一前缀与固定分隔符，使IDE将card__header等视为完整符号索引，而非拆分匹配；需确保共用block前缀、禁用非BEM混用、避免无主类名及空格选择器。
BEM 类名结构天然适配 IDE 的符号索引机制，补全时能精准匹配到组件上下文，而不是一堆泛化词。
为什么 VS Code 或 WebStorm 输入 card 就能列出 card__header、card--loading 而不是 user-card、cart-item
BEM 强制使用统一前缀（block 名）+ 固定分隔符（__ 和 --），IDE 的语言服务在扫描 CSS/HTML 时，会把 card__header 当作一个完整符号索引，而非拆成 “card” 和 “header” 两个独立词。这和搜 btn 会捞出 button、submit-btn、btn-primary 完全不同——后者没有结构约束，补全结果全是噪音。
常见错误是写成 .button + .button--large + .icon--close 混用，结果输入 button 时补全列表里夹着 icon--close（因为都含 button 字串），IDE 根本分不清语义边界。
- 必须确保所有相关类名共用同一 block 前缀，如
search-form__input、search-form__submit、search-form--compact - 禁用非 BEM 风格的类名混入，比如在同一组件中同时存在
search-form__input和input-field - 如果用了 CSS Modules，补全依赖的是编译后类名（如
SearchForm_input__abc123），需确认构建配置中localIdentName保留了原始 block 名
为什么 header__logo--hidden 比 hidden-logo 更容易被补全识别
顺序和语义权重决定补全优先级：header__logo--hidden 以具象 block 名开头，IDE 在索引时默认将首段作为主键；而 hidden-logo 以状态词开头，补全引擎无法判断它是“某个组件的隐藏态”，还是“一个叫 hidden 的 logo 组件”。
立即学习“前端免费学习笔记（深入）”；
实际场景中，你在 JSX 里写 className={styles.header__logo--hidden}，编辑器能根据 styles. 后的前缀直接过滤出该模块导出的所有 BEM 变体；但若写成 className="hidden-logo"，就完全脱离模块上下文，补全失效。
- block 名必须具象（如
user-avatar），不能是泛称（如item、box），否则补全时大量同名 block 冲突 - 避免在 block 名中塞修饰词（如
large-card），它会让card前缀失效，破坏补全连贯性 - Element 和 Modifier 必须严格依附 block，禁止出现
__logo--hidden这种无主类名，否则 IDE 无法建立归属关系
预处理器嵌套写法怎么不破坏补全效果
Sass/Less 的嵌套语法（如 .card { &__title { } }）本身不影响补全，真正出问题的是编译后输出——如果最终 CSS 里生成的是 .card .card__title（带空格），那这个选择器根本不会被 IDE 当作可补全符号索引；只有生成 .card__title 这种单类名，才能进符号表。
验证方法很简单：打开编译后的 CSS 文件，搜索 card__title，确认它是否独立成行、无前置空格或标签选择器。
- 禁止在 Sass 中写
.card { .card__title { } }，这会编译出空格选择器 - 允许用
&--hovered，但必须确保父级是.card，否则card--hovered会丢失 block 上下文 - 构建后执行
grep -r "\.[a-z]\+ \.[a-z]" dist/，能快速发现残留的嵌套选择器，它们会让补全变弱甚至失效
补全准确性的关键不在编辑器设置，而在类名是否真正构成可推导的语义链——form__submit-button--disabled 这一串字符里，每个段落都在回答“它属于谁、它是什么、它现在怎样”，IDE 只是忠实地把这套逻辑翻译成提示项。一旦命名松动（比如漏掉 form__ 前缀），补全就退化成字符串模糊匹配。
