Block名必须业务语义化、全局唯一且可独立复用，如promotional-banner、order-summary；禁用位置、状态、数字等上下文绑定词，确保能脱离页面存在、可测试、可跨项目引用。
Block 名太“业务化”不是问题，真正的问题是它被写成了临时需求代号或带上下文的短语，比如 homepage-hero-banner、cart-step-2-summary——这类名字在 PRD 里可能成立，但在代码里不可复用、不可测试、无法收敛。
Block 名必须能脱离页面存在，否则就不是 Block
一个合法的 Block 名，得满足：能单独导出、能写单元测试、能被其他项目引用。如果删掉当前页面 HTML，这个组件还能跑起来、有明确输入输出，那它才配叫 Block。
-
homepage-hero-banner❌ —— “homepage”是位置，“hero”是视觉描述，“banner”是泛称；三者叠加等于没定义职责 -
marketing-banner✅ —— 表达了业务意图（市场推广）、可复用（首页/活动页/弹窗都能用）、有明确数据结构（标题+副标+CTA） -
cart-step-2-summary❌ —— 绑定了流程步骤编号，一旦步骤调整，类名就得全量替换 -
cart-order-summary✅ —— “order-summary”是电商通用功能点，PRD 里必然出现，且逻辑闭环（展示商品、价格、优惠、总计）
怎么从 PRD 里准确提取 Block 名
别抄需求标题，要找最小可交付、跨页面复用的功能颗粒。常见误判点：
- 看到“顶部通栏广告”就写
top-banner→ 实际应为promotional-banner（“顶部”是布局，不是业务） - 看到“用户登录弹窗”就写
login-modal→ 应为auth-flow或sign-in-dialog（“弹窗”是载体，“身份认证流程”才是业务本质） - PRD 写“我的订单页右侧推荐位” → Block 名不能含“右侧”，而应是
related-orders-recommendation（“相关订单推荐”是功能点，位置由布局系统控制）
当业务方给的名字太长或太模糊时，怎么协商
直接拿 BEM 的落地成本反推：如果名字导致组件无法被复用、无法被搜索、无法被自动化校验，那就不是命名问题，是功能边界没对齐。
立即学习“前端免费学习笔记（深入）”；
- 拒绝接受带数字/位置/状态的词：
section-3、sidebar-user-card、active-tab - 要求业务方确认该模块是否在多个页面出现、是否有独立埋点、是否会被 A/B 测试切换——答案为“是”，就具备 Block 资格
- 把命名卡点前置到需求评审环节：不定义清楚
user-profile-card和member-badge的职责边界，开发阶段一定会返工
最常被忽略的一点：Block 名不是写给 CSS 看的，是写给未来三个月要改需求、修 Bug、做 AB 实验的自己看的。它得让人一眼看出“这东西改了会影响哪些页面”，而不是靠 grep 搜完再逐个打开 HTML 确认。
