bem 表格结构应以业务功能为 block（如 user-list-table），行、单元格作为 element，列职责用 modifier 标识；禁用 colgroup，列宽/对齐/响应式均通过 element modifier 控制；原生标签仅保语义，样式全由 bem 类接管；modifier 需分层：职责类必选、状态类可选、交互类严格限定。
表格结构如何对应BEM的Block–Element–Modifier
表格本身是天然的嵌套结构，但直接套用 table 作 Block 容易失控——因为 thead、tbody、tr、td 都有语义和默认样式，强行统一前缀反而增加维护成本。更稳妥的做法是：以业务功能为 Block 边界，比如 user-list-table 或 order-summary-table，而非泛泛叫 table。
行、列、单元格不单独建 Block，全部作为 Element 存在：
-
user-list-table__row（替代原生tr，用于包裹整行） -
user-list-table__cell（替代td/th，统一控制内边距、对齐、换行） -
user-list-table__header-cell（显式声明表头，避免依赖th的隐式语义） - 列无独立 DOM 节点，用
user-list-table__cell--status这类 Modifier 标识列职责，而非试图给“第3列”加类名
为什么不能用 colgroup + col 控制列宽或样式
colgroup 在多数浏览器中不支持伪类、背景、border 等关键样式，且 React/Vue 等框架中动态渲染 col 元素常导致错位。BEM 不解决这个底层限制，但能帮你避开陷阱：
- 列宽统一收口到
user-list-table__cell--name和user-list-table__cell--date的width或flex-basis - 需要列对齐时，不用
col.align="right"，改用user-list-table__cell--amount+text-align: right - 响应式列隐藏？加 Modifier：
user-list-table__cell--phone--hidden@md（配合媒体查询），比操作col更可控
tr 和 td 原生标签还能用吗？怎么和 BEM 类共存
可以保留，但必须明确角色：它们只负责语义与基础表格结构，所有样式通过 BEM 类接管。常见错误是同时写 <tr class="user-list-table__row"> 又保留 <code>tr:hover 规则，结果 hover 效果被 BEM 类覆盖或冲突。
实操要点：
- 重置原生样式：
tr, td, th { background: transparent; border: none; padding: 0; } - BEM 类全量接管交互：
.user-list-table__row:hover .user-list-table__cell控制悬停背景 - 避免在 CSS 中写
tr.user-list-table__row—— 选择器冗余，且当某天换成div模拟表格时需批量修改 - 如果用
display: grid实现表格布局，BEM 类名照旧，只是 DOM 结构变了，样式层完全解耦
单元格状态叠加时 Modifier 怎么命名才不爆炸
一个 user-list-table__cell 可能同时是“金额列”“负数”“不可编辑”“高亮”，全堆 Modifier 如 user-list-table__cell--amount--negative--disabled--highlighted 会失控。关键不是禁止叠加，而是分层：
- 职责类（必选，定义列语义）：
user-list-table__cell--price、user-list-table__cell--status - 状态类（可选，运行时添加）：
user-list-table__cell--error、user-list-table__cell--pending - 交互类（严格限定数量）：
user-list-table__cell--editable（仅两个值：有 / 无，不用--readonly） - 禁止出现三段式 Modifier，如
--price--negative；负数应由 JS 添加--negative，与列职责分离
复杂表格真正难的不是命名，而是让设计师、前端、后端对同一列的语义达成一致——比如“订单状态”列，到底是 --status 还是 --order-status，这个边界一旦模糊，后面所有 Modifier 都会漂移。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
