BEM通过类名固化样式归属关系，使“谁写的、在哪用的、能不能动”一查即知；强制业务语义块名、限定修饰符语义、目录级物理隔离，从源头防控长周期项目中的样式污染、语义漂移与维护失控。
因为BEM把样式归属关系固化在类名里，而不是靠文件位置、嵌套深度或团队默契——长周期项目最怕的不是写错，而是“谁写的、在哪用的、能不能动”，BEM让这三个问题一查即知。
类名自带上下文，避免“改一个样式要开五个文件”
维护成本随时间增长的核心，是样式来源越来越难追溯。没有BEM时，看到.btn，你得猜它来自global.css、header.css还是某个组件的index.scss；而.search-form__submit--disabled直接告诉你：这是搜索表单里的提交按钮，当前处于禁用态。
- 审查元素时，类名本身就能定位到对应模块文件（比如
search-form/目录） - 全局搜索
search-form__能精确命中所有相关样式，不会误伤其他btn类 - 删除一个废弃模块时，删掉
search-form/目录即可，不用担心.btn被其他地方复用而不敢删
修饰符(--modifier)约束状态表达，防止语义漂移
长周期项目里，最隐蔽的坑是类名含义悄悄变味。比如早期.btn--large只用于首页主按钮，半年后有人在弹窗里也加了这个类，结果尺寸冲突；又或者--dark本意是背景色，后来被用来控制文字色、边框色，最后没人说得清它到底管什么。
-
--modifier只允许描述状态（--disabled、--loading）或明确变体（--primary、--outline），禁止描述位置（--left）、视觉（--blue）或容器（--in-header） - CI阶段用
stylelint-selector-bem-pattern拦截.btn--blue这类写法，从源头卡住语义发散 - 当需要支持暗色模式时，
[data-theme="dark"] .search-form__input比.search-form__input--dark更可控——后者容易被滥用成“所有暗色相关都塞进去”
块级命名强制业务语义，拒绝“通用类”膨胀
项目越老，.container、.wrapper、.flex这类泛化类越多，它们看似省事，实则让样式作用域彻底失效：改.container的max-width，可能同时影响页头、弹窗、侧边栏。
立即学习“前端免费学习笔记（深入）”；
- BEM要求
block名必须带业务语义：.user-profile-card优于.card，.product-list-grid优于.grid - 同一UI模式在不同业务场景下，应建不同block：管理后台的
.admin-log-table和用户端的.order-history-table分开维护，互不干扰 - 禁止为图标、按钮等基础元素单独建
icon--home这种类——它们应属于某个block的element，如.nav-item__icon--home
构建时聚合+运行时隔离，兼顾开发效率与线上稳定性
长周期项目常面临“改一点，测一片”的困境。BEM本身不解决加载问题，但配合现代构建策略，能显著降低连带风险。
- 所有block样式按目录组织（
components/button/button.css），构建时用@import或import.meta.glob()聚合，既保持物理隔离，又输出单文件避免HTTP请求碎片化 - 禁用HTML中直接
<link href="button.css">——散装引入会让顺序错乱、缓存失效、无法做Tree-shaking - 对高复用低变更的block（如
.modal、.tooltip），抽成独立包供多项目引用；对高变更的（如.campaign-banner），保留动态加载能力，避免全量更新
真正难的不是写出符合BEM规范的类名，而是坚持让每个新组件都从block开始思考：它是否真的独立？它的element是否只属于它自己？一旦某处妥协写了个.btn--campaign，后续就可能蔓延出.btn--admin、.btn--mobile——BEM的约束力，只在每行代码都较真时才生效。
