必须分步改造table结构：先加语义容器（caption、thead、tbody、th），再修正colspan/rowspan逻辑，最后验证JS/CSS隐式依赖是否断裂。
直接改 <table> 结构风险极高，尤其老项目里常混着布局用法、JS 绑定、CSS 选择器强依赖 class 名。必须分步切，每步可验证、可回滚。<h3>先识别哪些表格该优先动</h3>
<p>别凭“看着乱”就开干。跑三行检查命令，信号明确再动手：</p>
<ul>
<li>
<code>document.querySelectorAll("table").length 超过 20 个？说明表格是核心数据载体，不能一刀切
Array.from(document.querySelectorAll("table")).some(t => t.querySelector("tr")?.children.length !== t.querySelector("thead tr")?.children.length) 返回 true？代表表头列数和数据行列数不一致，colspan/rowspan 混用严重，语义已断裂<caption></caption> 缺失、<thead> 和 <code><tbody> 错位或缺失，或 <code><th> 全被写成 <code><td>，说明结构基础已失效，必须优先修复<h3>第一步：只加语义容器，不动内容结构</h3>
<p>目标不是立刻重写，而是让现有 HTML “活下来”，并暴露问题。所有改动仅限插入标准语义标签：</p>
<ul><li>给每个 <code><table> 加上 <code><caption></caption>（哪怕临时写“数据表”），确保 Lighthouse 的 heading-levels 不报错<tr> 包进 <code><thead>，其余包进 <code><tbody>；已有 <code><tfoot> 的保留，没有的先不加<li>把所有 <code><td> 表头文字换成 <code><th>，但保留原有 class 和 inline style——只为恢复语义，不碰样式层<p>这步做完，无障碍工具能正确朗读表头，JS 仍能通过 <code>querySelector("td") 找到元素，零兼容风险。
立即学习“前端免费学习笔记（深入）”；
第二步：替换错误的单元格合并逻辑
colspan 和 rowspan 是最易出错的点，常见错误包括：<th colspan="3">总览</th> 却没对应三列数据、跨行合并后 <tbody> 行数错乱、用 <code>rowspan 实现“视觉分组”而非真实数据关系。
- 用
document.querySelectorAll("th[colspan], td[colspan], th[rowspan], td[rowspan]")扫出所有合并单元格 - 对每个匹配项，检查其所在行索引和跨列/行数是否与后续行实际单元格数量匹配；不匹配就拆——宁可多几行重复表头，也不留歧义
- 绝对避免
<th rowspan="5">ID</th>这类写法，除非你能确认后面 4 行都严格保持相同列结构；否则改用<th>ID</th>+ 每行重复 ID 列更安全
第三步：验证 JS 和 CSS 是否断裂
重构后最隐蔽的问题是“不报错但不工作”。重点查三类断裂：
- 旧 JS 是否还读
el.getAttribute("data-id")？而你已把data-id改成data-row-id——这类迁移必须同步更新所有 JS 引用点 - CSS 是否用
.table-wrap tr:nth-child(even)这种强依赖 DOM 层级的选择器？<thead> 插入后，<code>:nth-child序号全变，得改成tbody tr:nth-of-type(even) - 右键任意
<table> → “Break on” → “Attribute modifications”，看 JS 是否因 class 删除意外触发重绘（比如旧代码监听 <code>.data-table变化）真正难的不是改标签，而是确认所有隐式依赖都被显式接管——尤其是那些没人记得为什么写的 data- 属性和 class 名。
