col标签的width属性仅在table-layout: auto下作为不可靠建议生效，在table-layout: fixed下完全被忽略；稳定控制列宽需依赖td/th的style.width配合fixed布局。
col 标签的 width 属性到底管不管用
直接说结论：col 标签的 width 属性在现代浏览器中**仅对表格自动布局（table-layout: auto）生效，且行为不可靠；在更常见的 table-layout: fixed 下完全被忽略**。很多开发者拖拽调整列宽后手动改 <col width="200">，发现没反应——不是代码写错了，是 CSS 布局模式压过了它。
真正起作用的是：表格单元格（<td>/<th>）的 width 内联样式、或通过 style.width 设置的值，配合 table-layout: fixed 才能稳定映射列宽。
-
table-layout: auto：浏览器按内容撑开列宽，<col width>仅作“建议”，常被忽略 -
table-layout: fixed：第一行（或<col>）决定列宽，但此时<col width>必须是像素值（如width="150"），百分比或auto无效 - 拖拽时若直接改
<col>的width属性，必须同步触发重排（例如修改<col>后再改一个<td>的style.width），否则多数浏览器不重绘
拖拽过程中如何实时更新列宽并保持映射关系
核心思路不是“只动 <col>”，而是让 <col> 成为宽度状态的**只读快照**，真实控制权交给 <th> 或 <td> 的 style.width。拖拽逻辑应：
- 监听
mousedown在列分隔线（比如<th>右侧伪元素）上，记录初始鼠标位置和当前列宽（从th.style.width或getComputedStyle(th).width读） -
mousemove时计算差值，更新当前<th>和对应所有<td>的style.width（注意：同一列的所有单元格需统一设宽，否则错位） - 拖拽结束时，同步更新对应
<col>元素的width属性（例如colEl.setAttribute('width', Math.round(newWidth) + '')），仅作后续序列化或服务端回传用 - 避免对
<col>使用style.width—— 它不响应 CSS 样式，设了也无效
为什么不能只靠 colgroup + width 实现拖拽响应
因为 <colgroup> 是纯声明式结构，没有事件能力，也不参与渲染树的尺寸计算链路。你无法给 <col> 绑定 mousedown，也无法用 ResizeObserver 监听它的“宽度变化”（它根本不会变——变的是单元格）。
立即学习“前端免费学习笔记（深入）”；
常见误操作：
- 试图给
<col>加cursor: col-resize—— 无效，它不可见也不响应鼠标 - 用
colEl.offsetWidth获取宽度 —— 返回0，因为它没有盒模型 - 拖拽后只改
<col width>，不碰<th>的style.width—— 页面无视觉变化
正确做法是：把拖拽手柄（::after 伪元素）加在 <th> 上，宽度更新目标锁定为 <th> 和同列 <td>，<col> 仅作数据镜像。
兼容 fixed 布局与自动布局的最小适配策略
如果表格需要支持两种 table-layout 模式，不要试图一套拖拽逻辑通吃。最简方案是强制使用 table-layout: fixed，并在初始化时确保：
- 每一列都有明确宽度来源：要么第一行
<th>带style.width，要么<col>有像素width属性，二者至少其一 - 所有
<th>和<td>不设white-space: nowrap以外的溢出控制（如text-overflow: ellipsis需配合width和overflow: hidden） - 拖拽库（如
react-table插件或自研）内部应缓存每列的“目标宽度”，而非依赖<col>的当前属性值读取 —— 因为 DOM 属性可能滞后于实际渲染
真要兼容 auto 布局，就得放弃列宽精确控制：拖拽只影响该列所有单元格的 min-width，由内容最终决定实际宽度，<col> 完全弃用。
