BEM 的命名结构使 CSS 按需加载可行且可自动化，因 .card__title 明确归属 card Block，工具可通过正则或 AST 静态提取；而泛化名如 .title 无法判定归属，须全量加载。
BEM 本身不直接提供按需加载能力，但它的命名结构和模块边界让 CSS 按需加载在工程层面变得可行、可推导、可自动化——没有 BEM，按需加载容易退化为手动维护或静态打包。
为什么 .card__title 能被工具准确识别并提取
BEM 类名自带语义归属和层级信息，是静态分析的天然锚点：
-
.card__title明确属于cardBlock，只要知道页面用了card，就能反向定位到对应 CSS 文件或代码块 - 工具（如
postcss-bem-linter、webpack的css-modules插件、或自研构建脚本）可通过正则或 AST 解析快速提取所有以card__开头的类名，无需运行时 DOM 遍历 - 对比
.title这种泛化名：它可能来自 header、article、modal 等任意模块，无法静态判定归属，只能全量加载或依赖人工标注
card--featured 这类修饰符如何避免冗余打包
Modifier 不是独立样式单元，而是 Block 的状态变体，必须与 Block 同时存在才生效：
- 构建时若检测到模板中未使用
card--featured，且无 JS 动态添加该类，则可安全剔除对应 CSS 规则（前提是 Modifier 未被全局 selector 泛化匹配） - 禁止写
.card--featured .card__title这类依赖结构的选择器——它会让工具误判.card__title的上下文，导致无法安全剔除 - 正确写法是
.card--featured .card__title→ 改为.card--featured .card__title保持单类命中，或用 SCSS 的&--featured &__title编译出.card--featured .card__title，确保选择器可被静态关联
为什么 main__hero 这类命名反而破坏按需加载可靠性
Block 名若绑定 DOM 容器或页面位置（如 main、header），会导致模块复用时样式错配，进而迫使开发者不敢剔除“看似没用”的规则：
立即学习“前端免费学习笔记（深入）”；
-
main__hero在首页存在，但在活动页复制使用时，实际逻辑已脱离main上下文，但样式仍被归入main模块——构建工具无法判断它是否该随main一起加载 - 真正可按需加载的 Block 应具备明确职责边界，例如
promo-banner，无论出现在main、sidebar或弹窗里，都指向同一份样式资源 - 一旦 Block 名含位置暗示（
top-nav、footer-link），就失去跨上下文复用能力，按需加载会因“不确定是否复用”而保守全量引入
真正决定按需加载成败的，不是 BEM 语法本身，而是 Block 划分是否真实反映功能边界——一个命名正确的 user-avatar 可被精准加载，而一个命名模糊的 avatar 或过度耦合的 profile-page__avatar，都会让工具失去判断依据。
