styles.button比styles.primary更可靠，因为button明确标识组件归属和语义上下文，而primary缺乏块级限定，易导致跨组件混淆、复用失控与调试困难。
因为CSS Modules只解决类名唯一性，不解决语义归属和协作意图——styles.primary和styles.icon到底属于哪个组件、谁该维护、能否复用，它一概不管。
为什么styles.button比styles.primary更可靠
CSS Modules把.button编译成Button_button_abc123，但如果你在文件里写的是.primary，它就变成Button_primary_xyz789。问题来了：这个primary是按钮的主态？还是标题的强调色？还是整个页面的高亮主题？没人能从名字本身判断。
-
button__icon明确表示“这是按钮里的图标”，即使哈希后变成Button_button__icon_Mx9k2，开发者仍能一眼定位到来源文件和上下文 - 搜索
button__icon能精准命中Button.module.css，而搜icon可能匹配出二十个文件 - 当组件被抽取为npm包时，
MyButton_button__icon天然携带归属信息；MyButton_icon则和Card_icon、Modal_icon完全同质，无法区分
不带BEM逻辑的CSS Modules容易踩哪些坑
常见错误现象：className={styles.container}在五个不同组件里反复出现，每个container含义完全不同；重构时删掉一个container，三个页面同时白屏。
- Element名缺失层级感：写
.text不如.button__text，后者说明“这是按钮内的文本”，不是全局文本样式 - Modifier滥用导致状态失控：
styles.active可能同时用于按钮、菜单项、标签页，JS切换时互相干扰 - 跨组件复用困难：想把
.card__header逻辑抽成基础样式？不行——它没绑定card上下文，单独用会丢失语义 - TypeScript类型推导失效：
const styles = { active: string; text: string }无法表达active只应作用于button块
如何在CSS Modules中轻量落地BEM逻辑
不需要照搬block__element--modifier全套，但必须守住三道线：块归属、元素直系、修饰符收敛。
- 块名必须与组件名一致且可映射：
UserCard.module.css里只允许出现.user-card及其子类，禁止.card或.profile-card - Element名用双下划线连接，且只能是名词：
.user-card__avatar✅，.user-card__show❌（动词属于JS控制范畴） - Modifier只修饰块或元素，不嵌套：
.user-card--featured✅，.user-card--featured__avatar❌ - 构建阶段加
stylelint-selector-bem-pattern校验，规则设为{ "componentName": "user-card" }，CI直接拦截破规提交
BEM命名逻辑不是为了让人多打几个字符，而是为了让类名在脱离源码上下文后依然能自我解释——这点在调试线上问题、接手他人模块、做Code Review时，比任何哈希值都管用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
