尧图网站开发 
我最初碰到表格嵌套的坑是在做一套旧系统页面重构的时候。那个页面里塞了一张报表里三层外三层全是表格结果在浏览器里看着好好的一旦用脚本去解析数据不是多一行就是少一列后来才发现问题根本不在脚本上而在HTML本身。HTML表格嵌套这个事看起来是写几个标签的事实际上牵扯到浏览器的容错解析机制、DOM结构生成、以及后续的数据抽取策略。这篇文章我打算把自己踩过的坑、查过的规范、写过的解析代码一次说清楚帮你在写页面和写爬虫的时候都能少走弯路。1. 嵌套表格为什么容易崩浏览器容错机制与隐式闭合1.1 浏览器到底是怎么读表格标签的很多人写HTML都是靠感觉写标签开门关门就行。但浏览器的HTML解析器并不是这么工作的它是一个有状态的状态机一点一点读字节流遇到什么标签就进入对应的“插入模式”。表格恰好是HTML里最严格的上下文之一因为table的内部结构必须按行、按单元格来组织不允许随便插入别的块级元素。这带来一个直接后果如果你在table里写了不合法的结构比如直接在tr下面又放了一个table浏览器不会报错它只会默默“修正”你的代码把看起来不合法的部分挪到一个它认为正确的位置。这个行为在HTML5规范里有个专门的名字叫 foster parenting就是浏览器像收养流浪猫一样把那些不属于表格内部的标签“寄养”到表格外面去。所以你会看到一种经典现象内层嵌套的表格从视觉上跑到了外层表格的上面或下面页面布局整个乱掉。这不是CSS的锅是HTML解析器对你的代码做了重排。1.2 常见错误写法和浏览器实际表现我在实际项目里收集了几种出现频率最高的错误嵌套写法它们的共同点是人类看起来合情合理浏览器看起来不可理喻。第一种在tr和td之间直接塞table。比如table tr td外层单元格内容/td /tr table trtd内层表格内容/td/tr /table /table这段代码在浏览器解析的时候内层table会被“踢”到外层表格外面变成两个并列的独立表格。因为你破坏了一个规则table的直接子元素只能是caption、colgroup、thead、tbody、tfoot、tr这些其他元素一律不走常规路线。第二种在表格里直接嵌套一个div块级元素。table trtd正常单元格/td/tr div这段内容想去哪/div /table浏览器会把div移到表格外面去结果就是表格被硬生生分成两段视觉上中间插了一块内容。我用Chrome实测过内联元素放在表格里通常还能被容忍块级元素几乎必被移出。第三种更隐蔽外层tr没写td直接在内层再开一个表格。规范的实现是有些模糊的不同浏览器会有微妙差异但结论都是结构错乱脚本解析时拿到的是你自己都看不懂的DOM。提示如果你想确认自己的表格是不是被浏览器“重排”了最简单的办法是打开开发者工具查看Elements面板看看DOM数是不是和源码一致。不一致的话就是解析器在帮你“纠正”代码了。1.3 嵌套表格的正确定位方式真正规范的做法其实非常朴实内层表格一定放在td或th里面作为单元格的内容存在。单元格是表格里“合法”的容器里面放别的东西浏览器不会干涉。table tr td table trtd内层表格A/td/tr /table /td td旁边还有普通单元格/td /tr /table写代码时记住这句话表格嵌套不是表格套表格而是单元格套表格。只要你把内层表格当成一个普通的块级内容放进单元格解析器就不会捣乱后续用脚本遍历DOM的时候也顺滑很多。这个原则适用于任何复杂的报表、商品参数对比、日程表这类结构。2. 表格内容模型为什么浏览器会自动插入tbody2.1 没有tbody浏览器也会给你造一个很多新手写表格只写table tr td不写tbody页面显示也没问题。但如果你打开开发者工具会发现浏览器已经默默往DOM里插了一个tbody。这不是浏览器闲得慌而是HTML规范里明确定义了table的子元素中tbody是合法选项当解析器遇到一个裸的tr时必须把它包装在一个tbody里。这就是代码里没写但DOM里有的原因。影响在哪儿如果你用table.children这种API去取行会拿不到东西因为直接子元素是tbody行都藏在它下面。反过来如果你用table.rows这个专有API浏览器会自动考虑所有tbody里的行结果又是对的。我在帮同事排查一个表格增删行功能时见过这种问题代码里写了一堆table.children[0]、table.children[1]结果元素一多就错位因为他根本没意识到有tbody这层东西存在。所以解析表格的时候能走官方API就尽量走官方API少自己数元素层级。2.2 thead、tfoot也有各自的规矩标准的表格结构里thead放表头、tbody放数据、tfoot放汇总。thead和tfoot在表格里最多各出现一次tbody可以出现多次。多次出现的tbody通常用来分组比如一个表格里前五行是“销售一部”后五行是“销售二部”。从解析角度看这种多tbody结构很友好因为你可以按组分块处理数据而不是每次都要自己判断行索引的边界。如果用代码生成表格建议也养成输出标准结构的习惯不仅语义清楚对无障碍访问也更友好。如果你用爬虫解析别人的页面遇到多tbody的情况也别慌遍历table.rows的时候它是按DOM顺序把所有tbody的行排在一起的你只需要额外记一下每行归属哪个tbody就行。2.3 colgroup和col的坑colgroup也是表格的重要子元素用来定义列宽或为整列设置公共样式。它不参与表格数据的解析却会影响列数计算。有个细节容易踩坑当表格同时存在colgroup和thead时有些脚本用table.rows[0].cells.length去判断总列数结果发现数量不对因为colgroup里的col元素算的是“视觉上的列跨度”而cells集合返回的是td/th的个数。这两者经常不一致。我的建议是解析列相关属性时优先读取实际单元格的colSpan来推断列数不要依赖col标签的数量。代码实现也要考虑到colgroup不一定存在的情况做好防御性判断。3. colspan和rowspan跨行跨列对解析的直接影响3.1 合并单元格的视觉逻辑colspan2表示这个单元格横跨两列rowspan2表示竖着占两行。这是表格里最常用的布局手段也是解析时最容易让数据错位的元凶之一。视觉上合并单元格就是一张“挖掉某些格子”的表格但实际上DOM结构里根本没有那些被挖掉的格子。比如一行里前一个单元格colspan2那这一行实际创收的td数量会比视觉列数少一个。如果你用纯遍历去逐个取单元格数据不做跨行列的补偿取出来的数据矩阵是歪的。我举一个非常典型的例子table tr td rowspan2分类/td td项目A/td td数值1/td /tr tr td项目B/td td数值2/td /tr /table这个表格视觉上是两行三列但第一行有3个td第二行只有2个td。如果直接按cells.length取每行的单元格数会发现行与行之间数量对不上。这时候正确的做法是把每个单元格抽象的“实际占位”铺成一个二维数组。3.2 把合并单元格铺平成规整行列的算法我写过一个简单函数来处理这件事核心思路是维护一个二维矩阵占位表遇到rowspan占多位时就提前把下面几行的位置占掉。function normalizeTable(table) { const rows table.rows; const grid []; for (let i 0; i rows.length; i) { const rowData []; const cells rows[i].cells; if (!grid[i]) grid[i] []; let cellIndex 0; for (let j 0; j cells.length; j) { // 跳过已经被上方rowspan占掉的位置 while (grid[i][cellIndex]) cellIndex; const cell cells[j]; const colSpan cell.colSpan || 1; const rowSpan cell.rowSpan || 1; const value cell.innerText.trim(); rowData[cellIndex] { value, rowSpan, colSpan }; // 把后续位置标记为已占用 for (let r 0; r rowSpan; r) { for (let c 0; c colSpan; c) { if (!grid[i r]) grid[i r] []; grid[i r][cellIndex c] OCCUPIED; } } cellIndex colSpan; } grid[i] grid[i].map((cell, idx) cell OCCUPIED ? (rowData[idx] || null) : (rowData[idx] || null)); } return grid; }这个函数做过一次“位置补偿”输出的grid就是一个规整的二维结构每一行长度一致合并单元格的数据会复制到它占用的每一个位置上。这样你再去做数据对比、导出Excel、或者渲染到Canvas都不会错位了。实测下来用这个逻辑处理绝大多数合并单元格场景都管用。唯一需要小心的是多个rowspan叠加交叉的情况那属于少数布局特例遇到时建议单独断点走查。3.3 合并单元格场景下解析的真实案例之前我一个做供应链系统的朋友需要把页面里的库存表导出成CSV。那个表格里每家供应商的“公司名称”这列几乎都做了rowspan横跨好几行商品明细。他一开始直接遍历trtd导出来的CSV里每次到合并单元格就少一格和Excel里对不齐。后来我让他用了上面这个铺平算法同一家供应商的名称只出现在第一行的位置后续行里往下复制CSV导出后行列完全对齐Excel里做透视表也正常了。做事编程别怕麻烦麻烦一次后面一劳永逸。到这里基本上把看懂表格结构说清楚了。接下来我们深入数据侧既然要从HTML解析数据那就要知道怎么高效拿到表格内容。4. 用DOM API提取表格数据rows和cells的正确用法4.1 表格专有API比通用选择器更可靠解析HTML表格数据时大部分人第一个想到的是document.querySelectorAll(td)然后遍历这些单元格。这种做法简单但它有一个致命弱点完全丢失了表格的结构信息。你不知道一个单元格属于哪一行也不知道哪一行是表头哪一行是数据。表格对象自己带了三个很有用的数组接口table.rows返回所有tr元素row.cells返回该行所有td和throw.rowIndex拿到行序号。用这些专有API遍历天然就是按行按列走的结构清晰代码也更好维护。我用table.rows写过一个快速把表格转成二维数组的函数配合上一节的铺平逻辑用来做数据分析的前置处理非常好用。这里的要点是先用table.rows锁定行再用cells集合锁定单元格不要绕道querySelectorAll否则你还要自己维护行列关系。4.2 嵌套表格的数据提取策略递归下沉如果在解析时真的遇到了合法嵌套的内层表格你的脚本就要有“分层处理”的觉悟。我的策略很简单遍历单元格时看一下td内部有没有table元素。如果有那么当前单元格的“文本内容”并不是一个纯文本而是一张子表。这时候你要不要解析它取决于业务要求。我写过一个递归函数来提取表格数据当发现单元格内有表格时会返回一个带层级标记的嵌套结构。function extractTableData(table) { const result []; for (let i 0; i table.rows.length; i) { const row table.rows[i]; const rowData []; for (let j 0; j row.cells.length; j) { const cell row.cells[j]; const nestedTable cell.querySelector(table); if (nestedTable) { rowData.push({ type: nested-table, data: extractTableData(nestedTable) }); } else { rowData.push({ type: text, data: cell.innerText.trim() }); } } result.push(rowData); } return result; }用这段代码去解析带嵌套表格的数据你得到的结果是层级清晰的JSON结构后续合不合并完全取决于业务。这种递归方式在爬虫领域尤其常用很多详情页的“参数表”其实就是嵌套表格你如果不做递归就只能拿到一大段没有结构的文本价值小得多。4.3 文本内容的清洗与空白处理解析表格数据时文本清洗是绕不开的一环。innerText有时候会带着一堆看不见的空白、换行符、nbsp;还有的表格会把数字分多块文本放在同一个单元格里比如金额和单位在不同span里。我一般会做三步清洗第一用textContent而不是innerText因为textContent更接近源码里的纯文本第二把\s这个正则全局替换成单个空格避免多个空格和换行干扰第三对核心字段做前后端一致的类型转换比如把数字字符串转成数值不要等到存进数据库再后悔。有一个容易被忽略的点表格里经常有隐藏的行或列比如加了hidden属性或display: none的。如果用innerText这些隐藏内容通常不会被取到但用textContent就会。解析前你需要明确业务需求是只要用户能看到的内容还是要源码里的全部内容。这个决策直接影响你的解析准确性。5. 从HTML表格到结构化数据JSON和CSV的转换实操5.1 表格转JSON保留层级是分清内外层的关键把表格转成JSON是最常见的需求特别是前端拿到后端给的数据要渲染成表格渲染前要清理数据或者爬虫拿到网页要提取数据。处理JSON转换时有一个核心决策表头到底怎么处理我遇到过三种情况一是表头在thead里数据在tbody里这种情况简单直接读thead的单元格做key再遍历tbody的行做value二是表头就在第一行没有thead这种就要把第一行特别处理三是表头涉及colspan一列对应多个层级这时候必须把多层表头“拍平”成单层key比如用大类-子类这种拼接方式。最后一种最容易出问题我在实际项目里见过某个财务系统表头有三层季度、月、指标名。我最后的处理方案是给JSON的key加上层级前缀比如Q1-1月-收入这样虽然有点丑但数据不会丢后续做图表也方便。下面是一个简单的转化函数支持表头在thead的场景function tableToJson(table) { const headers []; const thead table.querySelector(thead); if (thead) { const headerRow thead.rows[0]; for (let cell of headerRow.cells) { headers.push(cell.innerText.trim()); } } else { const firstRow table.rows[0]; for (let cell of firstRow.cells) { headers.push(cell.innerText.trim()); } } const data []; const startRow thead ? 1 : 2; const rows table.rows; for (let i startRow; i rows.length; i) { const obj {}; const cells rows[i].cells; for (let j 0; j headers.length; j) { obj[headers[j]] cells[j] ? cells[j].innerText.trim() : ; } data.push(obj); } return data; }注意这里的startRow逻辑只对结构规整的表格有效。如果表格里存在rowspan你得先用第3节的铺平函数把表格归整之后再走JSON转换否则索引cells[j]完全可能取错列。5.2 表格转CSV逗号和引号的转义别偷懒CSV的规则比JSON简单但坑也深。它没有层级把所有数据排成一张扁平的二维表用逗号分隔用换行分记录。一旦单元格内容里出现了逗号、换行或双引号就必须给这个字段加上双引号括起来并且把字段内部的转义成这是RFC 4180的规则。我看过不少人在这一步犯懒直接Array.join(,)就完事最后打开CSV文件列错位不得不返工。正确写法是先对每个字段做转义处理function escapeCsvField(field) { if (field.includes(,) || field.includes() || field.includes(\n)) { return ${field.replace(//g, )}; } return field; }缩写没有朝CSV的转义规则妥协你处理一个字段就少一分出错的可能。做导出功能时把这行函数封装好能省掉后面大量的bug排期。5.3 常见脏数据场景表格解析遇到的脏数据比想象中的多。我罗列几个高频场景第一单元格文本前后有大量空白。这通常是因为源码里写了缩进格式textContent读出来就带空格。建议统一trim()再用正则把内部多个空白压缩成一个。第二数字格式不一致比如“1,234.56”这种千分位文本。做数据统计之前必须先去掉千分位符号并转成数字否则求和的时候整个字段是NaN。第三单元格内既有文本又有隐藏节点。比如一个td里放了若干span和一段超链接innerText会把这些全部拼接在一起毫无分隔。这时你要么按业务提取特定子元素要么在拼接时自己加分隔符。这些坑一个比一个隐蔽处理的方法也五花八门但总的原则是一致的先看清表格的真实DOM结构再写解析逻辑千万别拿“看起来差不多”的页面当基准一旦上游改了页面你的解析脚本随时会失灵。6. 高频问题排查与避坑速查6.1 表格解析问题对照表我在处理表格解析和表格渲染时总结了一个问题排查对照表遇到类似现象可以直接照方抓药现象大概率原因处理方案嵌套表格显示到了外层表格外面表格直接嵌套在tr下触发foster parenting把内层表格移进td内DOM里多了不认识的原生tbody源码没写tbody浏览器自动补全不要手动假设子元素层级用table.rows访问行数对、列数少存在colspan合并单元格使用铺平算法补偿合并占位列数对、行数多存在rowspan合并单元格遍历时跳过被跨行占用的位置innerText取出来的数据有大量空白源码缩进和隐藏换行用textContent加正则清洗单元格里既有文本又有子表格合法嵌套表格结构未区分用递归方式提取嵌套表格并分层导出CSV后Excel列错位单元格内容含逗号或引号未转义按RFC 4180规则对字段做转义这个表我用了很久每次排查问题都从“现象”倒推“原因”比漫无目的地打断点快很多。实际上很多表格解析的bug都不是逻辑写错而是在第一步读结构的时候就理解错了。6.2 三个值得单独说说的实战技巧第一个技巧解析之前先把表格的DOM结构打印出来看一眼。很多人上来就写循环结果解析逻辑跑偏浪费几个小时。用console.dir(table)看上两秒结构清楚之后代码写起来非常顺。第二个技巧处理完合并单元格、嵌套表格之后把自己铺平后的数据矩阵打印到控制台和页面上肉眼看到的表格做一次“视觉对比”。这一步能发现很多程序上看不出来的错位问题。我就是靠这种对比方式抓到过好几处因为rowspan补偿出错导致的数据错位。第三个技巧如果解析对象是不可控的第三方页面一定要在脚本里加上异常保护。一个小改动比如对方把td换成了th或者表格上加了一个内层table你的脚本就能从“完全失灵”变成“有部分结果”。我通常会在每个单元格取值时都做一层兜底判断const value cell ? cell.innerText.trim() : ;就这么一行代码能让你的解析脚本健壮很多。6.3 一些基于经验的小结如果在表格解析这件事上只能给一条建议我会说先想清楚你要的是“视觉上看到的表格”还是“代码里的语义结构”这两者在HTML表格里经常不是一回事。视觉上你看到的是一个行列规整、有些格子合并、有些格子包含更多内容的表格。但代码里它是一个层级嵌套的DOM树合并单元格会缺失位置信息嵌套表格会打断普通文本流。解析的过程说白了就是把“视觉结构”映射回“逻辑数据表”的过程无论你是做爬虫、做导出、做表格渲染还是做数据可视化弄懂这层映射关系之后所有问题都会变得明朗起来。HTML表格嵌套这件事表面上是一个标签规范问题其实是理解浏览器解析机制和数据处理逻辑的入口。我在实际项目里靠这套思路解决过不少看起来“玄学”的表格问题每次最后发现都是把视觉表格和逻辑表格混为一谈了。如果你也在写类似的数据解析或者报表页面建议把第3节的铺平算法和第4节的递归提取存下来这两个函数能覆盖大多数日常场景。做页面也好写爬虫也好少在工具上折腾一些就能多在真正的业务逻辑上多花些时间。 
我最初碰到表格嵌套的坑是在做一套旧系统页面重构的时候。那个页面里塞了一张报表里三层外三层全是表格结果在浏览器里看着好好的一旦用脚本去解析数据不是多一行就是少一列后来才发现问题根本不在脚本上而在HTML本身。HTML表格嵌套这个事看起来是写几个标签的事实际上牵扯到浏览器的容错解析机制、DOM结构生成、以及后续的数据抽取策略。这篇文章我打算把自己踩过的坑、查过的规范、写过的解析代码一次说清楚帮你在写页面和写爬虫的时候都能少走弯路。1. 嵌套表格为什么容易崩浏览器容错机制与隐式闭合1.1 浏览器到底是怎么读表格标签的很多人写HTML都是靠感觉写标签开门关门就行。但浏览器的HTML解析器并不是这么工作的它是一个有状态的状态机一点一点读字节流遇到什么标签就进入对应的“插入模式”。表格恰好是HTML里最严格的上下文之一因为table的内部结构必须按行、按单元格来组织不允许随便插入别的块级元素。这带来一个直接后果如果你在table里写了不合法的结构比如直接在tr下面又放了一个table浏览器不会报错它只会默默“修正”你的代码把看起来不合法的部分挪到一个它认为正确的位置。这个行为在HTML5规范里有个专门的名字叫 foster parenting就是浏览器像收养流浪猫一样把那些不属于表格内部的标签“寄养”到表格外面去。所以你会看到一种经典现象内层嵌套的表格从视觉上跑到了外层表格的上面或下面页面布局整个乱掉。这不是CSS的锅是HTML解析器对你的代码做了重排。1.2 常见错误写法和浏览器实际表现我在实际项目里收集了几种出现频率最高的错误嵌套写法它们的共同点是人类看起来合情合理浏览器看起来不可理喻。第一种在tr和td之间直接塞table。比如table tr td外层单元格内容/td /tr table trtd内层表格内容/td/tr /table /table这段代码在浏览器解析的时候内层table会被“踢”到外层表格外面变成两个并列的独立表格。因为你破坏了一个规则table的直接子元素只能是caption、colgroup、thead、tbody、tfoot、tr这些其他元素一律不走常规路线。第二种在表格里直接嵌套一个div块级元素。table trtd正常单元格/td/tr div这段内容想去哪/div /table浏览器会把div移到表格外面去结果就是表格被硬生生分成两段视觉上中间插了一块内容。我用Chrome实测过内联元素放在表格里通常还能被容忍块级元素几乎必被移出。第三种更隐蔽外层tr没写td直接在内层再开一个表格。规范的实现是有些模糊的不同浏览器会有微妙差异但结论都是结构错乱脚本解析时拿到的是你自己都看不懂的DOM。提示如果你想确认自己的表格是不是被浏览器“重排”了最简单的办法是打开开发者工具查看Elements面板看看DOM数是不是和源码一致。不一致的话就是解析器在帮你“纠正”代码了。1.3 嵌套表格的正确定位方式真正规范的做法其实非常朴实内层表格一定放在td或th里面作为单元格的内容存在。单元格是表格里“合法”的容器里面放别的东西浏览器不会干涉。table tr td table trtd内层表格A/td/tr /table /td td旁边还有普通单元格/td /tr /table写代码时记住这句话表格嵌套不是表格套表格而是单元格套表格。只要你把内层表格当成一个普通的块级内容放进单元格解析器就不会捣乱后续用脚本遍历DOM的时候也顺滑很多。这个原则适用于任何复杂的报表、商品参数对比、日程表这类结构。2. 表格内容模型为什么浏览器会自动插入tbody2.1 没有tbody浏览器也会给你造一个很多新手写表格只写table tr td不写tbody页面显示也没问题。但如果你打开开发者工具会发现浏览器已经默默往DOM里插了一个tbody。这不是浏览器闲得慌而是HTML规范里明确定义了table的子元素中tbody是合法选项当解析器遇到一个裸的tr时必须把它包装在一个tbody里。这就是代码里没写但DOM里有的原因。影响在哪儿如果你用table.children这种API去取行会拿不到东西因为直接子元素是tbody行都藏在它下面。反过来如果你用table.rows这个专有API浏览器会自动考虑所有tbody里的行结果又是对的。我在帮同事排查一个表格增删行功能时见过这种问题代码里写了一堆table.children[0]、table.children[1]结果元素一多就错位因为他根本没意识到有tbody这层东西存在。所以解析表格的时候能走官方API就尽量走官方API少自己数元素层级。2.2 thead、tfoot也有各自的规矩标准的表格结构里thead放表头、tbody放数据、tfoot放汇总。thead和tfoot在表格里最多各出现一次tbody可以出现多次。多次出现的tbody通常用来分组比如一个表格里前五行是“销售一部”后五行是“销售二部”。从解析角度看这种多tbody结构很友好因为你可以按组分块处理数据而不是每次都要自己判断行索引的边界。如果用代码生成表格建议也养成输出标准结构的习惯不仅语义清楚对无障碍访问也更友好。如果你用爬虫解析别人的页面遇到多tbody的情况也别慌遍历table.rows的时候它是按DOM顺序把所有tbody的行排在一起的你只需要额外记一下每行归属哪个tbody就行。2.3 colgroup和col的坑colgroup也是表格的重要子元素用来定义列宽或为整列设置公共样式。它不参与表格数据的解析却会影响列数计算。有个细节容易踩坑当表格同时存在colgroup和thead时有些脚本用table.rows[0].cells.length去判断总列数结果发现数量不对因为colgroup里的col元素算的是“视觉上的列跨度”而cells集合返回的是td/th的个数。这两者经常不一致。我的建议是解析列相关属性时优先读取实际单元格的colSpan来推断列数不要依赖col标签的数量。代码实现也要考虑到colgroup不一定存在的情况做好防御性判断。3. colspan和rowspan跨行跨列对解析的直接影响3.1 合并单元格的视觉逻辑colspan2表示这个单元格横跨两列rowspan2表示竖着占两行。这是表格里最常用的布局手段也是解析时最容易让数据错位的元凶之一。视觉上合并单元格就是一张“挖掉某些格子”的表格但实际上DOM结构里根本没有那些被挖掉的格子。比如一行里前一个单元格colspan2那这一行实际创收的td数量会比视觉列数少一个。如果你用纯遍历去逐个取单元格数据不做跨行列的补偿取出来的数据矩阵是歪的。我举一个非常典型的例子table tr td rowspan2分类/td td项目A/td td数值1/td /tr tr td项目B/td td数值2/td /tr /table这个表格视觉上是两行三列但第一行有3个td第二行只有2个td。如果直接按cells.length取每行的单元格数会发现行与行之间数量对不上。这时候正确的做法是把每个单元格抽象的“实际占位”铺成一个二维数组。3.2 把合并单元格铺平成规整行列的算法我写过一个简单函数来处理这件事核心思路是维护一个二维矩阵占位表遇到rowspan占多位时就提前把下面几行的位置占掉。function normalizeTable(table) { const rows table.rows; const grid []; for (let i 0; i rows.length; i) { const rowData []; const cells rows[i].cells; if (!grid[i]) grid[i] []; let cellIndex 0; for (let j 0; j cells.length; j) { // 跳过已经被上方rowspan占掉的位置 while (grid[i][cellIndex]) cellIndex; const cell cells[j]; const colSpan cell.colSpan || 1; const rowSpan cell.rowSpan || 1; const value cell.innerText.trim(); rowData[cellIndex] { value, rowSpan, colSpan }; // 把后续位置标记为已占用 for (let r 0; r rowSpan; r) { for (let c 0; c colSpan; c) { if (!grid[i r]) grid[i r] []; grid[i r][cellIndex c] OCCUPIED; } } cellIndex colSpan; } grid[i] grid[i].map((cell, idx) cell OCCUPIED ? (rowData[idx] || null) : (rowData[idx] || null)); } return grid; }这个函数做过一次“位置补偿”输出的grid就是一个规整的二维结构每一行长度一致合并单元格的数据会复制到它占用的每一个位置上。这样你再去做数据对比、导出Excel、或者渲染到Canvas都不会错位了。实测下来用这个逻辑处理绝大多数合并单元格场景都管用。唯一需要小心的是多个rowspan叠加交叉的情况那属于少数布局特例遇到时建议单独断点走查。3.3 合并单元格场景下解析的真实案例之前我一个做供应链系统的朋友需要把页面里的库存表导出成CSV。那个表格里每家供应商的“公司名称”这列几乎都做了rowspan横跨好几行商品明细。他一开始直接遍历trtd导出来的CSV里每次到合并单元格就少一格和Excel里对不齐。后来我让他用了上面这个铺平算法同一家供应商的名称只出现在第一行的位置后续行里往下复制CSV导出后行列完全对齐Excel里做透视表也正常了。做事编程别怕麻烦麻烦一次后面一劳永逸。到这里基本上把看懂表格结构说清楚了。接下来我们深入数据侧既然要从HTML解析数据那就要知道怎么高效拿到表格内容。4. 用DOM API提取表格数据rows和cells的正确用法4.1 表格专有API比通用选择器更可靠解析HTML表格数据时大部分人第一个想到的是document.querySelectorAll(td)然后遍历这些单元格。这种做法简单但它有一个致命弱点完全丢失了表格的结构信息。你不知道一个单元格属于哪一行也不知道哪一行是表头哪一行是数据。表格对象自己带了三个很有用的数组接口table.rows返回所有tr元素row.cells返回该行所有td和throw.rowIndex拿到行序号。用这些专有API遍历天然就是按行按列走的结构清晰代码也更好维护。我用table.rows写过一个快速把表格转成二维数组的函数配合上一节的铺平逻辑用来做数据分析的前置处理非常好用。这里的要点是先用table.rows锁定行再用cells集合锁定单元格不要绕道querySelectorAll否则你还要自己维护行列关系。4.2 嵌套表格的数据提取策略递归下沉如果在解析时真的遇到了合法嵌套的内层表格你的脚本就要有“分层处理”的觉悟。我的策略很简单遍历单元格时看一下td内部有没有table元素。如果有那么当前单元格的“文本内容”并不是一个纯文本而是一张子表。这时候你要不要解析它取决于业务要求。我写过一个递归函数来提取表格数据当发现单元格内有表格时会返回一个带层级标记的嵌套结构。function extractTableData(table) { const result []; for (let i 0; i table.rows.length; i) { const row table.rows[i]; const rowData []; for (let j 0; j row.cells.length; j) { const cell row.cells[j]; const nestedTable cell.querySelector(table); if (nestedTable) { rowData.push({ type: nested-table, data: extractTableData(nestedTable) }); } else { rowData.push({ type: text, data: cell.innerText.trim() }); } } result.push(rowData); } return result; }用这段代码去解析带嵌套表格的数据你得到的结果是层级清晰的JSON结构后续合不合并完全取决于业务。这种递归方式在爬虫领域尤其常用很多详情页的“参数表”其实就是嵌套表格你如果不做递归就只能拿到一大段没有结构的文本价值小得多。4.3 文本内容的清洗与空白处理解析表格数据时文本清洗是绕不开的一环。innerText有时候会带着一堆看不见的空白、换行符、nbsp;还有的表格会把数字分多块文本放在同一个单元格里比如金额和单位在不同span里。我一般会做三步清洗第一用textContent而不是innerText因为textContent更接近源码里的纯文本第二把\s这个正则全局替换成单个空格避免多个空格和换行干扰第三对核心字段做前后端一致的类型转换比如把数字字符串转成数值不要等到存进数据库再后悔。有一个容易被忽略的点表格里经常有隐藏的行或列比如加了hidden属性或display: none的。如果用innerText这些隐藏内容通常不会被取到但用textContent就会。解析前你需要明确业务需求是只要用户能看到的内容还是要源码里的全部内容。这个决策直接影响你的解析准确性。5. 从HTML表格到结构化数据JSON和CSV的转换实操5.1 表格转JSON保留层级是分清内外层的关键把表格转成JSON是最常见的需求特别是前端拿到后端给的数据要渲染成表格渲染前要清理数据或者爬虫拿到网页要提取数据。处理JSON转换时有一个核心决策表头到底怎么处理我遇到过三种情况一是表头在thead里数据在tbody里这种情况简单直接读thead的单元格做key再遍历tbody的行做value二是表头就在第一行没有thead这种就要把第一行特别处理三是表头涉及colspan一列对应多个层级这时候必须把多层表头“拍平”成单层key比如用大类-子类这种拼接方式。最后一种最容易出问题我在实际项目里见过某个财务系统表头有三层季度、月、指标名。我最后的处理方案是给JSON的key加上层级前缀比如Q1-1月-收入这样虽然有点丑但数据不会丢后续做图表也方便。下面是一个简单的转化函数支持表头在thead的场景function tableToJson(table) { const headers []; const thead table.querySelector(thead); if (thead) { const headerRow thead.rows[0]; for (let cell of headerRow.cells) { headers.push(cell.innerText.trim()); } } else { const firstRow table.rows[0]; for (let cell of firstRow.cells) { headers.push(cell.innerText.trim()); } } const data []; const startRow thead ? 1 : 2; const rows table.rows; for (let i startRow; i rows.length; i) { const obj {}; const cells rows[i].cells; for (let j 0; j headers.length; j) { obj[headers[j]] cells[j] ? cells[j].innerText.trim() : ; } data.push(obj); } return data; }注意这里的startRow逻辑只对结构规整的表格有效。如果表格里存在rowspan你得先用第3节的铺平函数把表格归整之后再走JSON转换否则索引cells[j]完全可能取错列。5.2 表格转CSV逗号和引号的转义别偷懒CSV的规则比JSON简单但坑也深。它没有层级把所有数据排成一张扁平的二维表用逗号分隔用换行分记录。一旦单元格内容里出现了逗号、换行或双引号就必须给这个字段加上双引号括起来并且把字段内部的转义成这是RFC 4180的规则。我看过不少人在这一步犯懒直接Array.join(,)就完事最后打开CSV文件列错位不得不返工。正确写法是先对每个字段做转义处理function escapeCsvField(field) { if (field.includes(,) || field.includes() || field.includes(\n)) { return ${field.replace(//g, )}; } return field; }缩写没有朝CSV的转义规则妥协你处理一个字段就少一分出错的可能。做导出功能时把这行函数封装好能省掉后面大量的bug排期。5.3 常见脏数据场景表格解析遇到的脏数据比想象中的多。我罗列几个高频场景第一单元格文本前后有大量空白。这通常是因为源码里写了缩进格式textContent读出来就带空格。建议统一trim()再用正则把内部多个空白压缩成一个。第二数字格式不一致比如“1,234.56”这种千分位文本。做数据统计之前必须先去掉千分位符号并转成数字否则求和的时候整个字段是NaN。第三单元格内既有文本又有隐藏节点。比如一个td里放了若干span和一段超链接innerText会把这些全部拼接在一起毫无分隔。这时你要么按业务提取特定子元素要么在拼接时自己加分隔符。这些坑一个比一个隐蔽处理的方法也五花八门但总的原则是一致的先看清表格的真实DOM结构再写解析逻辑千万别拿“看起来差不多”的页面当基准一旦上游改了页面你的解析脚本随时会失灵。6. 高频问题排查与避坑速查6.1 表格解析问题对照表我在处理表格解析和表格渲染时总结了一个问题排查对照表遇到类似现象可以直接照方抓药现象大概率原因处理方案嵌套表格显示到了外层表格外面表格直接嵌套在tr下触发foster parenting把内层表格移进td内DOM里多了不认识的原生tbody源码没写tbody浏览器自动补全不要手动假设子元素层级用table.rows访问行数对、列数少存在colspan合并单元格使用铺平算法补偿合并占位列数对、行数多存在rowspan合并单元格遍历时跳过被跨行占用的位置innerText取出来的数据有大量空白源码缩进和隐藏换行用textContent加正则清洗单元格里既有文本又有子表格合法嵌套表格结构未区分用递归方式提取嵌套表格并分层导出CSV后Excel列错位单元格内容含逗号或引号未转义按RFC 4180规则对字段做转义这个表我用了很久每次排查问题都从“现象”倒推“原因”比漫无目的地打断点快很多。实际上很多表格解析的bug都不是逻辑写错而是在第一步读结构的时候就理解错了。6.2 三个值得单独说说的实战技巧第一个技巧解析之前先把表格的DOM结构打印出来看一眼。很多人上来就写循环结果解析逻辑跑偏浪费几个小时。用console.dir(table)看上两秒结构清楚之后代码写起来非常顺。第二个技巧处理完合并单元格、嵌套表格之后把自己铺平后的数据矩阵打印到控制台和页面上肉眼看到的表格做一次“视觉对比”。这一步能发现很多程序上看不出来的错位问题。我就是靠这种对比方式抓到过好几处因为rowspan补偿出错导致的数据错位。第三个技巧如果解析对象是不可控的第三方页面一定要在脚本里加上异常保护。一个小改动比如对方把td换成了th或者表格上加了一个内层table你的脚本就能从“完全失灵”变成“有部分结果”。我通常会在每个单元格取值时都做一层兜底判断const value cell ? cell.innerText.trim() : ;就这么一行代码能让你的解析脚本健壮很多。6.3 一些基于经验的小结如果在表格解析这件事上只能给一条建议我会说先想清楚你要的是“视觉上看到的表格”还是“代码里的语义结构”这两者在HTML表格里经常不是一回事。视觉上你看到的是一个行列规整、有些格子合并、有些格子包含更多内容的表格。但代码里它是一个层级嵌套的DOM树合并单元格会缺失位置信息嵌套表格会打断普通文本流。解析的过程说白了就是把“视觉结构”映射回“逻辑数据表”的过程无论你是做爬虫、做导出、做表格渲染还是做数据可视化弄懂这层映射关系之后所有问题都会变得明朗起来。HTML表格嵌套这件事表面上是一个标签规范问题其实是理解浏览器解析机制和数据处理逻辑的入口。我在实际项目里靠这套思路解决过不少看起来“玄学”的表格问题每次最后发现都是把视觉表格和逻辑表格混为一谈了。如果你也在写类似的数据解析或者报表页面建议把第3节的铺平算法和第4节的递归提取存下来这两个函数能覆盖大多数日常场景。做页面也好写爬虫也好少在工具上折腾一些就能多在真正的业务逻辑上多花些时间。