colspan="n"仅扩展单元格渲染宽度，不改变表格逻辑结构；需确保每行单元格colspan总和等于逻辑列数，否则浏览器自动补空或错位，pdf/excel导出时更易出错。
HTML 表格中 colspan 属性的基本写法与常见错觉
直接写 colspan="2" 就能跨两列？没错，但多数人忽略它只作用于当前单元格的「渲染宽度」，不改变表格逻辑结构。表头（<th>）用 <code>colspan 后，后续行的单元格数量必须对齐，否则浏览器会自动补空格或错位——这不是 bug，是 HTML 表格模型的强制对齐行为。
常见错误现象：<th colspan="3">销售额</th> 后紧跟 <td>Q1</td>
<td>Q2</td>（只写了 2 个 <td>），结果最后一列被“吞掉”或错行。<ul>
<li>
<code>colspan 的值必须是正整数，不能为 0 或负数，否则会被浏览器忽略
<th> 和 <code><td> 的 <code>colspan 值加起来，应等于该行“逻辑列数”（即未合并时应有的列总数）动态生成表格时如何安全计算 colspan 值
服务端模板（如 Jinja2、Thymeleaf）或前端 JS 拼接表格时，硬编码 colspan 极易出错。关键不是“算几列”，而是“当前单元格覆盖哪几列索引”。建议维护一个列索引映射数组，例如：colSpanMap = [null, 3, null, null, 2] 表示第 2 列（索引 1）跨 3 列，第 5 列（索引 4）跨 2 列。
使用场景：导出带合并表头的 Excel（通过 html2canvas 或 SheetJS 渲染 HTML 表格时），若 colspan 计算偏差，生成的 Excel 列宽/边框会断裂。
- 避免用循环次数推算
colspan，改用目标列范围差值：比如合并从列 2 到列 4（含），则colspan = 4 - 2 + 1 = 3 - JS 中操作 DOM 后再读取
cell.colSpan可能返回 1（即使 HTML 写了colspan="3"），因浏览器已做归一化；应优先读取cell.getAttribute('colspan') - React/Vue 等框架中，
colspan是属性而非 prop，需写成colSpan（驼峰），且值为 number 类型，传字符串会触发警告
当 colspan 遇上 CSS table-layout: fixed
设了 table-layout: fixed 后，colspan 单元格可能不按预期撑开，尤其在列宽由 <col> 定义时。这是因为 fixed 布局下，浏览器先按 <col> 或首行单元格宽度分配列宽，再把 colspan 单元格“铺”在已定宽度的列区域上——如果总列宽不够，内容会被截断或换行。
性能影响：开启 fixed 能提升大表格渲染速度，但会让 colspan 行为更难预测，调试时建议先关掉它定位问题。
- 确保
<col>标签数量与逻辑列数一致，不要漏写；<col span="2">不等价于两个<col>，它只定义一个“占两列”的列样式，不参与colspan对齐计算 - 用
min-width配合colspan更可靠：给跨列单元格加style="min-width: 200px;"，比依赖列宽总和更可控 - Chrome DevTools 的 Elements 面板里，右键单元格 → “Edit as HTML”，修改
colspan值后回车可实时验证，比刷新页面快得多
服务端渲染中 colspan 错位导致 PDF 导出异常
用 wkhtmltopdf、WeasyPrint 或 Puppeteer 渲染带 colspan 的 HTML 表格为 PDF 时，最常出现表头文字偏左、边框断裂、甚至整行消失。根本原因不是工具缺陷，而是这些引擎对 HTML 表格模型的支持比浏览器更严格：它们要求每行的列计数必须完全闭合，且不允许隐式列推导。
容易被忽略的地方：Puppeteer 的 page.pdf() 默认 viewport 是 A4 宽度（约 595px），若表格本身超宽又用了 colspan，某些列可能被裁剪，而裁剪位置恰好在跨列单元格边界，造成视觉“断开”。
- 导出前用 JS 注入校验逻辑：遍历每行，累加
cell.colSpan || 1，与基准列数比对，不等则 console.warn 并高亮该行 - 避免在
<thead> 外使用 <code>colspan，PDF 引擎对<tbody> 中跨列支持更弱<li>如必须动态列数，改用 CSS Grid 模拟表头（配合 <code>aria-label保无障碍），绕过colspan的语义绑定限制
