最稳方法是用 document.querySelectorAll(‘table tr’) 提取行，跳过表头或单独读取 <th>，再对每个 <td>/<th> 取 textContent.trim() 映射为对象，按列索引对齐字段名与值，避免 innerHTML/innerText 问题及 class/data-key 依赖。
用 document.querySelectorAll 提取表格行数据最稳
html 表格转 json 的核心是“把每行 <tr> 映射成一个对象”，而不是硬啃整个 dom 树。直接遍历 <tr>，跳过表头（或单独读取 <th>），再对每个 <td> 或 <th> 取 textcontent，能避开 innerhtml 解析混乱、空格换行干扰等问题。
常见错误现象：innerText 在某些浏览器里会合并空白、吞掉 <br>；innerHTML 会带标签、编码乱；用 jQuery.text() 又多一层依赖。
- 优先用
document.querySelectorAll('table tr')，再用Array.from()转数组方便 filter/map - 表头列名建议从第一行
<th>或首行<td>提取，统一用.map(el => el.textContent.trim()) - 数据行从第二行开始（
index > 0），避免把表头当数据 - 遇到合并单元格（
colspan/rowspan）直接跳过或打日志警告——这类结构本身就不适合扁平 JSON
字段名和值怎么对齐？靠表头索引，别靠 class 或 data-key
很多人想给 <td> 加 data-field="name"，结果维护成本飙升：改个 HTML 就要同步改 JS，而且容易漏。真实项目里，表头顺序稳定、语义明确，用列位置对齐最可靠。
使用场景：后台导出的报表页、管理后台的静态数据列表、测试用的 demo 表格——这些表结构基本固定，列顺序不会随便调。
- 先提取表头数组，比如
['姓名', '邮箱', '状态'] - 遍历每行数据时，用
cells[i].textContent.trim()和表头数组下标一一对应 - 如果某列是空单元格，
textContent是空字符串，可按需转成null或undefined，别留空白字符串 - 避免用
cell.getAttribute('class')做字段判断——CSS 类名可能复用、可能动态增删，不可信
JSON.stringify 前必须处理特殊字符和类型
表格里常有换行符、全角空格、emoji、HTML 实体（如 ）、甚至内联 <script>（虽然不该有）。直接塞进 JSON 容易触发解析失败或 XSS 风险。
立即学习 “ 前端免费学习笔记（深入）”；
性能影响：对每格做 replace(/s+/g, ' ') 比正则全局清理快，但若表格超大（>1000 行），建议节流或分片处理。
- 对每个单元格值做
.replace(/[rnt]+/g, '').replace(/u00a0/g,' ').trim() - 遇到
<code>>这类实体，用简单映射替换，别上DOMParser——太重，且可能执行脚本 - 数字列（如 ID、金额）可尝试
parseFloat()或parseInt()，但务必加isNaN()判断，防止把“—”或“N/A”转成NaN - 布尔列（如“是否启用”）别靠字符串相等判断，用白名单：
['是', '启用', 'true', '1'].includes(text)
遇到嵌套表格或跨页表格怎么办？先拒绝，再拆解
标准表格转 JSON 的前提是“单层二维结构”。一旦出现 <table> 套 <table>、或分页由 JS 动态加载，就不再是“提取”问题，而是“数据建模”问题。
容易踩的坑：写一堆递归去 flatten 嵌套 <tr>，结果字段名冲突、层级丢失、性能骤降；或者监听 scroll 等待懒加载完成，却没考虑网络失败或超时。
- 发现子
<table>直接跳过整行，或抛错提示：“不支持嵌套表格，请检查 HTML 结构” - 分页表格只处理当前 DOM 中存在的
<tr>，别试图模拟点击“下一页”——那是 E2E 测试的事 - 真需要多页数据？让后端提供 API，前端只负责展示；表格只是视图，不是数据源
- 如果必须拼接多页，用
fetch拿原始 JSON 数据，而不是从多个 HTML 表格里扒
最麻烦的永远不是怎么转，而是表格本身有没有定义清楚“哪列是主键”“空值代表什么”“日期格式是否统一”。代码可以修，语义模糊只能返工。
