拖拽调整表格列宽时，正确做法是仅修改 th 元素的 style.width 属性，并同步更新同一列所有 td 的 style.width，而非操作 标签的 width 属性；拖拽区域需依赖 getBoundingClientRect() 计算边缘坐标来触发，同时必须将 mouseup 事件监听绑定到 document 对象上，避免状态残留导致拖拽失效。

先提炼几个关键要点：表格列宽拖拽这个功能，表面简单，实际暗藏多处陷阱。核心思路是——直接更新单元格的内联样式，而不是依赖标签。为什么？因为浏览器渲染时，真正起作用的字段是th及其同列td的style.width，而的width属性在table-layout: fixed模式下会完全失效。很多开发者拖拽后发现宽度没变化，根源就在这里：只改了，单元格样式纹丝不动，自然白费力气。

拖拽时仅改 th.style.width，别碰 的 width 属性

具体操作顺序如下：拖拽开始前，从th.style.width或getComputedStyle(th).width中读取当前宽度。优先使用后者，因为初始状态下th可能没有内联样式，直接读style.width会拿到空值。拖拽过程中，实时设置th.style.width = newWidth + 'px'，同时遍历该列所有td元素，同步更新它们的style.width。这一步至关重要，漏掉任何一个td，视觉上就会出现错位——表头已经变宽，内容列还卡在原宽度，整体非常不协调。

至于的width属性，仅适合在拖拽完成后写回，作为数据持久化或服务端同步的手段，而不是用来控制实时渲染的。

判断拖拽区域必须依靠坐标计算，不能依赖 hover 或 class

鼠标是否落在列右边缘 5px 范围内，必须通过实时坐标来判断，不能简单加个:hover伪类解决。否则要么误触发，要么漏触发，体验很差。具体做法是：对每个th绑定onmousedown事件，在回调里调用getBoundingClientRect()计算右边缘位置：const rightEdge = th.getBoundingClientRect().left + th.offsetWidth，然后判断if (Math.abs(event.clientX - rightEdge) <= 5)，满足条件时激活拖拽。

注意，这里要避免使用event.offsetX——在 Firefox 和某些移动端浏览器上，这个属性值不可靠。统一采用getBoundingClientRect()配合clientX，才是最稳妥的方案。另外，只对thead tr:first-child th绑定事件，防止内容行的单元格干扰拖拽逻辑。

table-layout: fixed 是刚需，且需确保第一行 th 有明确宽度

没有table-layout: fixed，列宽会跟随内容自动重排，拖拽效果飘忽不定，就像在泥潭里拖绳子。但光设置这个属性还不够，第一行单元格必须拥有可读取的宽度值，否则浏览器无法锚定列的基准。初始化时，强制设置table.style.tableLayout = 'fixed'，然后遍历第一行th，用th.offsetWidth给th.style.width赋值。这里有一个技巧：如果表格没有内联宽度，先让offsetWidth落地，再将其转换为像素值。一定要避开百分比或auto，像素值才是稳定的。

松手后列宽“弹回去”？大概率是 mouseup 监听没挂到 document 上

一个容易被忽略的细节：当鼠标快速拖出表格区域时，table.onmouseup根本不会触发，导致状态残留，后续拖拽操作失效或宽度错乱。解决方案：在mousedown时，立即绑定document.onmouseup和document.onmousemove，然后在mouseup回调中清理：document.onmouseup = null，document.onmousemove = null。或者使用addEventListener配合removeEventListener，避免重复绑定。同时，别忘了重置table.style.width，否则总宽度失衡会导致其他列被挤压或撑开。

根据实践经验，最容易踩的坑是：拖拽过程中没有同步更新同列所有td的style.width，结果表头变宽了，内容列还卡在原宽度，视觉上直接错位。这不算 Bug，只是忘了做这件事。所以记住口诀：改th，同步td，不碰，事件挂到document上，搞定。