为什么直接使用 .button 会导致他人样式被覆盖 CSS 有一个长期存在的全局作用域问题。像 .button 这种通用类名，一旦在多个模块、不同团队甚至第三方库中重复出现，后加载的规则会无声无息地覆盖前者，且不产生任何提示。特别是在微前端架构、SSR 项目，或者老旧系统中叠加新组件时——一个 .
CSS 有一个长期存在的全局作用域问题。像 .button 这种通用类名，一旦在多个模块、不同团队甚至第三方库中重复出现，后加载的规则会无声无息地覆盖前者，且不产生任何提示。特别是在微前端架构、SSR 项目，或者老旧系统中叠加新组件时——一个 .icon 类可能同时作用于导航图标、弹窗关闭按钮和表格操作列。修改一处，三处同时出错。
典型的样式冲突场景包括：margin 突然增大，display 被强制改为 inline-block，字体颜色意外继承自某个远古的 body 规则。打开开发者工具排查后，才发现是另一份 CSS 文件中同名类导致的干扰。
长期稳定更新的攒劲资源： >>>点此立即查看<<<
依赖团队自觉并不可靠。npm 包自带的样式、UI 库的局部引入，甚至 create-react-app 默认注入的 index.css 都可能埋下风险。应避免使用语义过强但泛滥的类名，例如 .header、.list、.content。即使使用 !important，也只是延迟冲突，让调试更困难。
BEM（Block__Element--Modifier）本质上通过命名约定建立逻辑边界，使类名自带上下文信息。其关键不在于类名长度，而在于能够反向定位来源。例如 .user-card__avatar--large 明确表明它属于 user-card 模块，是头像元素，且处于大尺寸状态——这一信息本身就能有效阻止误复用。
实操要点：
.search-bar，不用 .bar；使用 .product-grid，不用 .grid__，Modifier 用双短横 --，这是硬性约定。避免写成 .searchBar_avatar 或 .search-bar-large.user-card .button 是反模式，应写为 .user-card__action-button.button--primary 必须与 .button 同时存在，否则基础样式无兜底BEM 解决的是命名空间污染，CSS Modules 解决的是作用域隔离，两者目标不同。BEM 在全局 CSS 中依然有效；而 CSS Modules 生成的哈希类名（如 Button_button__abc123）实际上暗合 BEM 思想——只是将 Block 名的绑定自动化了。
容易踩的坑：