colspan属性用于让单元格横向占据N个逻辑格子，而非单纯变宽；必须同步删除被覆盖位置的其他td/th，否则导致结构错位、表头对不齐、CSS选择器失效及可访问性问题。
直接用 colspan 属性，但必须同步删掉被覆盖位置的其他 <td> 或 <code><th>，否则表格结构会错位——浏览器不报错，但视觉和可访问性都会出问题。
<h3>colspan="N" 不是“让单元格变宽”，而是“占掉 N 个格子”</h3>
<p>比如一行本该有 5 列，你在第一个 <code><td> 上写 <code>colspan="3"，那它就吃掉了第 1、2、3 列的位置。这一行剩下的单元格加起来只能占 2 列，也就是最多再写两个 <td>（各占 1 列）。
<ul>
<li>写成 <code><td colspan="3">A</td>
<td>B</td>
<td>C</td>
<td>D</td> → 实际列数变成 3+1+1+1 = 6，超出预期，下一行对不齐
<td colspan="3">A</td>
<td>B</td>
<td>C</td> → 总列数 = 3+1+1 = 5，匹配预期colspan="2px" 或 colspan="two" 会被浏览器完全忽略跨列合并后表头和数据行对不齐？检查 <thead> 和 <code><tbody> 的列总数
<p>常见于多级表头：比如 <code><thead> 里第一行用 <code>colspan="2" 合并了“姓名/年龄”，第二行又写了两个独立 <th>，这时 <code><tbody> 每行必须严格对应最终展开后的列数（比如 3 列），否则边框断裂、CSS 选择器失效。
<ul>
<li>用 <code>Array.from(document.querySelectorAll('thead tr:first-child th')).map(el => el.colSpan || 1).reduce((a, b) => a + b) 算出表头总列数
<tbody><tr> 的实际列数（同样用 <code>el.colSpan || 1 累加）
document.querySelector('td:nth-child(3)') 这类选择器就会选错位置colspan 超出当前行实际列数会怎样
比如表格定义为 4 列，某个 <td colspan="6"> 会渲染出来，但超出部分不占空间、不撑开宽度，右侧留白，响应式断点下尤其明显。<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill6712" title="Wechat HTML Publisher"><img
src="https://img.php.cn/upload/skill/000/000/081/179109368394970.jpg" alt="Wechat HTML Publisher" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill6712" title="Wechat HTML Publisher">Wechat HTML Publisher</a>
<p>直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。</p>
</div>
<a href="/xiazai/skill6712" title="Wechat HTML Publisher" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div>
<ul>
<li>浏览器静默截断，不会警告也不会报错</li>
<li>用 <code>getBoundingClientRect().width 对比父 <tr> 宽度，能发现实际渲染宽度远小于预期
<li>安全做法：动态生成时，每行都做列数校验，避免靠“肉眼数”或草稿估算</li>
<p>最麻烦的不是写错属性，而是漏删被覆盖位置的单元格——DOM 结构一旦错位，后续所有样式、脚本、屏幕阅读器行为都可能连锁异常，且很难一眼看出根源。</p>
</tr>
