订单列表页面应拆分为语义独立、可复用的 Block（如order-list-table、order-filters、order-summary-card），而非包裹在无功能的order-page容器中；每个Block需具备独立输入输出边界、脱离上下文正常运行的能力，并严格遵循BEM命名规范与结构收敛原则。
订单列表页面不是“一个页面”，而是多个语义独立、可复用的 Block 组合，比如 order-list-table、order-filters、order-summary-card；直接套用 .page 或 .order-page 会导致样式污染、复用失败、调试困难。
为什么不能把整个订单页包进 order-page 这个 Block
因为 order-page 不表达任何具体功能，它只是个容器壳子：没有输入输出边界，无法被其他页面复用，且一旦修改它的 padding 或 max-width，所有子元素（如表格、筛选栏）布局都可能意外偏移。更严重的是，order-page__filters 和 order-page__table 在其他上下文（比如弹窗内嵌订单预览）根本没法单独拎出来用。
常见错误写法：
<div class="order-page"><br> <div class="order-page__filters"></div><br> <div class="order-page__table"></div><br></div>
问题在于：两个子模块完全被父级绑架，类名里塞了冗余上下文，且违背 BEM “Block 必须可独立存在” 原则。
order-list-table 怎么命名行、列、状态才不爆炸
表格本身不是 Block，业务功能才是。所以用 order-list-table 而非 table 或 order-table —— 后者太泛，前者明确指向「订单列表」这个场景。
-
order-list-table__row表示一行数据，状态交由 Modifier 承载：order-list-table__row--pending、order-list-table__row--cancelled -
order-list-table__cell是通用单元格，列职责靠 Modifier 区分：order-list-table__cell--order-id、order-list-table__cell--status、order-list-table__cell--amount - 表头单独声明：
order-list-table__header-cell，避免依赖th的隐式语义 - 禁止出现
order-list-table__row__cell或order-list-table__cell--pending—— 前者是嵌套 Element，后者混淆了“列职责”和“行状态”
order-filters 和 order-summary-card 如何划清边界
每个 Block 必须能脱离当前页面独立存在、渲染、测试。判断标准很简单：把它复制到另一个页面（比如用户个人中心），是否仍能正常工作？
立即学习“前端免费学习笔记（深入）”；
-
order-filters应包含完整交互逻辑：日期范围选择、状态多选、搜索输入、重置按钮；它的order-filters__submit-btn不应依赖外部 JS 控制，而应封装提交行为 -
order-summary-card是聚合统计模块，含“待发货数”“7日成交额”等字段；它的order-summary-card__stat-value必须能响应不同单位（¥ / 件 / %），不能硬编码样式 - 两者之间禁止样式耦合：不允许在
order-filters的 SCSS 里写& + .order-summary-card，也不允许用order-filters__container这种模糊命名来包裹其他 Block
BEM 最容易被忽略的点，是 Block 的“可移植性”不是靠命名技巧，而是靠 HTML 结构收敛——每个 Block 的根元素必须只挂一个 BEM 类，内部不再依赖父级类名触发样式；一旦发现某个元素必须靠 .order-list-table .order-filters 才能生效，说明边界已经模糊，该拆了。
