应删除表格中所有仅用于样式控制的冗余嵌套标签，如div.table-wrapper、无语义的div或span，改用原生table语义结构与现代CSS（padding、flex、max-width等）实现布局与样式，同时补全colgroup确保列宽可控。

表格里嵌套

是最高频冗余点

很多团队把 <td> 当成“画布”，在里面塞 <code><div class="card"><div class="content"><p>文字</p></div></div>，这直接破坏了表格的语义边界和渲染效率。浏览器要为每个 <code><div> 创建节点、计算样式、参与布局树，而这些对表格数据展示毫无必要。<p>真正需要的只是结构化数据承载能力：<code><td> 本身支持 padding、text-align、vertical-align，也支持 flex/grid 子布局（只要不破坏语义层级）。<code><tr> 和 <code><td> 已经是语义完备的容器，额外包裹层只会让 JS 选择器变慢、无障碍树变混乱。<ul><li>删掉所有仅用于样式控制的 <code><div>：比如 <code><td><div class="text-center">内容</div></td> → 直接给 <td> 加 <code>class="text-center"

避免在 <td> 里用 <code><div> 模拟 <code><section></section> 或 <article></article> —— 表格单元格不是内容区块，它只负责单个数据单元

检查 <td> 内是否含 <code>aria-labelledby 或 role 属性，若存在，说明该 <div> 承担可访问性职责，不能直接删，需评估能否迁移到 <code><td> 自身<h3>table 标签外的“保护性 wrapper”大多可删</h3> <p>常见写法：<code><div class="table-wrapper"><div class="scrollable"><table>...</table></div></div>。这类双层包裹常被当作“防止溢出”或“统一 margin”的惯性方案，但现代 CSS 完全能替代，且更轻量。

问题在于：每多一层，就多一次 DOM 插入 + 样式继承计算；在移动端弱网下，实测深度超 6 层的表格页，domInteractive 时间比扁平结构高出 200ms+。

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

立即学习“前端免费学习笔记（深入）”；

• 滚动控制直接用 table { display: block; overflow-x: auto; }，配合 tbody { display: block; max-height: 300px; } 控制体区滚动
• 外边距统一由 table 自身承担，无需 div.table-wrapper；若需响应式约束宽度，用 max-width + margin: 0 auto
• 全局搜索 class="table-wrapper" 或 id="tbl-container"，确认是否被 JS 的 querySelector 或 CSS 后代选择器（如 .report-page .table-wrapper table）强依赖 —— 若无，则删

重复的 结构要按需精简

<thead> 和 <code><tbody> 是语义必需，但 <code><tfoot> 经常被无意义添加：比如空标签、仅含 <code> 、或与 <thead> 内容完全一致。这类冗余不仅增加解析负担，还干扰屏幕阅读器播报顺序（会先读 <code><tfoot> 再读 <code><tbody>）。<p>更隐蔽的问题是“伪语义”：<code><thead><tr><th colspan="5">报表汇总</th></tr></thead> 这类写法看似合理，实则混淆了表头（column header）与标题（section title），应改用 <caption></caption>。

• 删掉空的 <tfoot>，除非真有汇总行需固定在底部（且该行逻辑上属于“脚注”，非重复表头）<li> <code><caption></caption> 替代 <thead> 里的“大标题行”：它专为表格提供可见+可访问的标题，且不影响列对齐逻辑<li>检查 <code><thead> 是否只含 <code><tr><th></th></tr> 结构；若出现 <tr><td></td></tr> 或嵌套 <div>，说明语义已错位，需重构<h3>data-* 属性和 class 名暴露的冗余信号</h3> <p>当看到 <code><table class="js-table-data" data-table-id="user-list">，或 <code><td data-cell-type="status" data-status-value="active">，这些属性往往意味着：原本可用语义标签/原生属性表达的含义，被降级为 JS 运行时识别的字符串。<p>这不是代码风格问题，而是结构腐化的征兆 —— 开发者不再信任 HTML 本身的表达力，转而用属性“打补丁”。结果就是：表格越来越难被 CSS 直接样式化，也越来越难被辅助技术理解。</p> <ul> <li>用 <code>role="grid" 替代 data-table-role="grid"；用 aria-sort="ascending" 替代 data-sort="asc"
• 将 data-cell-type="status" 这类标记，改为用 <td class="status-cell"> + CSS 层级控制，既保留可维护性，又避免 JS 强耦合<li>全局搜索 <code>data- 前缀中含 table、row、cell 的属性，逐个判断是否真需运行时识别 —— 多数情况，CSS 类名或语义标签已足够

表格重构最易被忽略的一点：<colgroup></colgroup> 和 <col> 的缺失会让后续样式维护成本翻倍。很多人删完冗余标签后，发现列宽控制全靠 <td style="width:120px">，这比删标签本身更危险 —— 它让结构和表现彻底纠缠，下次加一列就得改几十个地方。重构时顺手补上 <code><colgroup></colgroup>，是真正让表格可持续演进的底线动作。