2026/9/7 14:33:12
FEATURED · 精选文章 
简介面向已掌握Bootstrap Table基础用法、希望提升列宽交互性的前端工程师这份压缩包提供了一整套列宽定制与拖动调整的实现方案特别适合数据管理后台、报表系统等需要灵活操作列宽的场景。资源共14个文件压缩包整体约117KB包含6个JavaScript脚本、6个CSS样式表、1个JSON数据文件和1个HTML示例页面其中bootstrap-table-colresize插件与colResizable-1.6.js负责拖动逻辑配套样式表负责界面外观。已有8414人学习下载。示例页面清晰展示了如何在表格列上通过data-width指定初始宽度并利用extensions选项启用columnResize功能让用户直接拖拽列头完成宽度调节。包内还包含Bootstrap Table主库、中文语言包及JSON示例数据整体代码结构清晰便于快速集成与本地化部署可直接作为实际项目中的参考实现节省插件接入与调试时间。 做后台管理系统这些年bootstrap table基本是我最常用的表格组件没有之一。这次接一个数据看板的重构需求需求方提了两个一开始让我觉得“这有什么难的”的要求表格列宽要能统一设置还要支持用户直接拖拽列头调整列宽。结果真正落地的时候才发现“可设置列宽和可拖动列宽”这行字背后牵扯到表格布局算法、事件绑定、数据持久化、滚动条联动一整套细节。这篇博客就把我的完整实现过程和踩坑记录分享出来给同样被这个需求折磨的同学一条可以照抄的路线。先说清楚这次项目的背景一个后台数据看板表格大概有二十多列字段包括日期、渠道、曝光量、点击率、消耗金额、转化成本、ROI等等。原来用的默认列宽字段一多屏幕根本放不下用户要看完一整行数据必须来回拖水平滚动条看左侧的维度再对比右侧的指标眼睛都快看花了。所以需求收敛成两条第一表格列宽要支持单独设置不同列不能一把尺子量到底第二用户可以直接在表头上拖拽调整列宽并且调整结果要能记住下次打开页面还是用户自己调好的样子。1. 需求复盘用户要的“可拖列宽”到底是什么1.1 数据看板场景下的宽表痛点这个项目里的表格不是简单的“展示数据”而是承载了运营同学每天的数据分析工作流。列一多问题就来了运营同学最关心的是“消耗金额”和“转化成本”这种核心指标结果这些列跟旁边的“渠道ID”列挤在一起数字被压得歪歪扭扭看的时候还得眯着眼数位数。另一个痛点是不同列的内容差异太大。“日期”列只需要十个字符的宽度“渠道名称”列可能需要二十个字符“备注”列甚至需要四十个字符。Bootstrap table默认的等宽策略显然不满足这种业务场景。用户需要的是把“日期”列压缩窄一点把“消耗金额”列拉宽让数字有呼吸感。1.2 Bootstrap table自带的宽度方案为什么不够Bootstrap table本身不是没有列宽相关的能力它提供了width属性可以给每一列指定宽度。但这里有个很坑的地方如果你用的是自适应布局表格列宽会按内容自动分配你设置的width值只能算是一个“建议值”浏览器会根据实际内容调整。更跟不上需求的是第二点拖拽调整列宽。Bootstrap table的核心库里没有现成的拖拽API你要么自己写事件逻辑要么依赖第三方插件。而且就算你实现了拖拽怎么把拖完的宽度存下来、怎么在下次渲染时恢复这些都得自己造轮子。所以这个需求的完整定义其实是指定列宽 拖拽调整 记忆持久化三者缺一不可。2. 让指定列宽真正生效布局模式与colgroup的配合2.1 为什么设置了width属性却不生效我一开始直接在columns配置里写{ field: cost, title: 消耗金额, width: 120 }刷新页面列宽纹丝不动。后来查了文档才发现Bootstrap table的宽度机制依赖两个条件一是表格要设置table-layout: fixed二是列宽要通过colgroup里的col元素来承载。如果没有固定布局浏览器会根据单元格内容自动计算宽度你在JS里配置的width值会被当成一个“最小内容宽度”的参考而不是一个确定值。这也是很多人配置了列宽却发现没生效的根因。2.2 用colgroup稳住列宽基线我最终的方案是在表格初始化之前手动生成一份colgroup配置并在columns里为每一列明确指定width。举个例子const columns [ { field: date, title: 日期, width: 100 }, { field: channel, title: 渠道, width: 130 }, { field: cost, title: 消耗金额, width: 120 } ]; // 初始化时把 width 写进 colgroup $(#table).bootstrapTable({ columns: columns, // 这两行是关键 tableWidth: 100%, // 通过这张表设置 });有人可能会问为什么不能直接设置width属性就行这里要解释一下Bootstrap table的内部机制初始化时它会根据columns的配置动态生成HTML表格结构包括colgroup和thead。如果你在列定义中设置了width它会生成对应的col stylewidth: 120px;。但如果你用onLoadSuccess之类的回调去动态修改列头就有可能导致colgroup没有同步更新出现“表头宽度变了内容列宽没变”的错位。所以我的建议是列宽的基线配置最好在初始化时就定好不要指望后期靠CSS修补。2.3 列宽参数的持久化策略第二个需求的“记忆功能”我用的是localStorage。用户拖完列宽之后把每一列的字段名和宽度值组成一个对象存起来function saveColumnWidths() { const widths {}; columns.forEach(col { const $headerCell $(#table thead th[data-field${col.field}]); widths[col.field] $headerCell.outerWidth(); }); localStorage.setItem(dashboard_table_col_widths, JSON.stringify(widths)); }下次进入页面时在列定义里做一次合并覆盖const saved JSON.parse(localStorage.getItem(dashboard_table_col_widths) || {}); const columns baseColumns.map(col { if (saved[col.field]) { col.width saved[col.field]; } return col; });之所以用outerWidth而不是直接读style.width是因为边框和padding会影响实际渲染宽度outerWidth取到的才是用户肉眼看到的那条线。3. 拖拽列宽的两条技术路线我为什么选了手写3.1 现成插件方案bootstrap-table-resizable与colresizable社区里其实有现成的方案最常用的是bootstrap-table-resizable它底层依赖colresizable这个jQuery插件。接入方式也简单把两个文件引入页面然后在表格配置里加一行resizable: true就能用了。我一开始也确实试了这个方案。但我遇到了几个问题第一它在某些版本下跟fixedColumns固定列插件配合得不太好左侧固定列会挡住拖拽手柄第二默认的拖拽范围没有限制用户可以把一列拖到几乎消失或者拖到把整个表格撑爆第三也是最重要的它拖拽后的宽度变化不会主动通知你要拿到最新的列宽数据需要额外写监听逻辑反而麻烦了。3.2 手写拖拽的代价与收益权衡了一下我决定自己写拖拽逻辑。手写的好处是每个行为都在自己掌控里拖拽手柄的样式可以自定义宽度范围可以做上下限限制拖拽过程中可以实时回馈拖完之后的同步逻辑也是自己说了算。代价当然也有需要理解表格布局的底层机制处理各种边缘情况还要兼容Bootstrap table动态渲染表格节点的时间点。但这个代价是值得的因为一旦自己掌握了这套逻辑后续做列宽的默认配置、按角色保存、按页面保存都变得很容易。插件很多时候是个黑盒黑盒里出了问题你只能干瞪眼。4. 手写列宽拖拽的核心实现从事件捕获到列宽同步4.1 给表头单元格装拖拽手柄Bootstrap table渲染完成后thead里的每个th就是我们的操作目标。我选择在每个th的右侧添加一个绝对定位的拖拽手柄这里有个小细节手柄不是放在th内部而是放在th的::after伪元素或一个独立span上。我的做法是在表格加载完成后遍历所有表头单元格插入一个span classresize-handlefunction addResizeHandles() { $(#table thead th).each(function() { // 避免重复插入 if ($(this).find(.resize-handle).length) return; $(this).append(span classresize-handle/span); }); }CSS部分.resize-handle { position: absolute; right: 0; top: 0; width: 6px; height: 100%; cursor: col-resize; z-index: 10; background: transparent; } .resize-handle:hover { background: rgba(0, 0, 0, 0.1); }注意th的position必须是relative否则手柄的absolute定位会找到更外层的容器去。我在这个坑里浪费了十分钟。4.2 mousedown、mousemove、mouseup三件套拖拽的核心逻辑是三段式mousedown时记录起始坐标和起始列宽mousemove时计算位移差值并更新列宽mouseup时解除事件绑定并触发保存。let isResizing false; let currentTh null; let startX 0; let startWidth 0; $(#table).on(mousedown, .resize-handle, function(e) { e.preventDefault(); isResizing true; currentTh $(this).closest(th); startX e.pageX; startWidth currentTh.outerWidth(); $(document).on(mousemove, onMouseMove); $(document).on(mouseup, onMouseUp); }); function onMouseMove(e) { if (!isResizing) return; const diff e.pageX - startX; let newWidth startWidth diff; // 宽度限制 if (newWidth 60) newWidth 60; if (newWidth 400) newWidth 400; currentTh.css(width, newWidth px); // 同步对应的 col 元素 const index currentTh.index(); $(#table colgroup col).eq(index).css(width, newWidth px); } function onMouseUp() { isResizing false; currentTh null; $(document).off(mousemove, onMouseMove); $(document).off(mouseup, onMouseUp); saveColumnWidths(); }这里有个很关键的细节e.preventDefault()一定要写否则拖拽过程中浏览器会默认选中表格中的文本导致屏幕上出现一片蓝色选区特别难看。另一个细节是为什么更新th之后还要同步更新colgroup。因为表格的列宽实际上是由colgroup里的col元素控制的th的宽度更多是展示层面的。如果你只改了th表格内容的td不会跟着变就会出现“表头拉宽了内容还是老样子”的撕裂效果。4.3 拖拽结束后同步回Bootstrap table的数据状态上面代码里每次mousemove都在更新DOM但Bootstrap table内部还有一份列宽的状态这个状态如果不更新下次你调用getOptions()拿到的列宽配置还是旧的对后续开发是个隐患。我的做法是在mouseup之后手动遍历一次列配置更新optionsfunction syncOptions() { const options $(#table).bootstrapTable(getOptions); options.columns[0].forEach(col { const $headerCell $(#table thead th[data-field${col.field}]); if ($headerCell.length) { col.width $headerCell.outerWidth(); } }); }需要注意options.columns是个二维数组因为Bootstrap table支持行分组和多个thead层级第一层columns[0]对应最外层表头。如果你的表头没有分组那columns[0]就是所有列。5. 我在实际项目中踩过的坑5.1 拖拽列宽后表头与表格内容错位第一次实现完拖拽后我遇到一个很奇怪的现象表头被拉宽了但对应列的内容还是窄的整张表格看起来像被错位扯了一下。排查后发现问题出在Bootstrap table的渲染机制上。它的表头和数据部分是分两个独立模块渲染的如果你给某一个th直接设置了宽度而colgroup里对应的col没有同步调整浏览器会根据col的宽度去渲染数据行。所以解决方案就是我上面代码里写的拖拽时不仅改th还要改colgroup里对应的col。第二次踩坑是初始化时设置了colWidths: [100, 200, 150]这种方式。Bootstrap table对纯数字数组的解析有时会失效尤其在widthUnit配置了百分比的情况下。我建议列宽宽度一律显式写成像素值别写百分比拖拽计算时会简单很多。5.2 表格存在水平滚动条时拖拽断触我们的看板表格列数多在1280px的屏幕上肯定会溢出于是出现了水平滚动条。这时拖拽右侧列的宽度就会出现一个极其烦人的问题拖拽过程中只要鼠标移到表格边界页面就会自动产生滚动导致pageX的位置一直在跳拖拽手柄跟手程度很差。这个事一开始我以为是代码问题后来发现是拖拽事件和滚动容器的事件发生了竞争。解决方案是在拖拽开始时给body加一个overflow: hidden的类拖拽结束后再移除function onMouseMove(e) { // ... document.body.style.overflow hidden; } function onMouseUp() { // ... document.body.style.overflow ; }但不推荐在每个mousemove里都做这个操作会有性能损耗我只在开始拖拽的第一次mousemove时加一次。5.3 与固定列、批量操作列的冲突表格的左侧有两个固定列一个是序号一个是复选框列用来做批量操作。Bootstrap table的固定列原理是把固定列复制出来单独渲染然后用绝对定位盖在表格上方。这就导致了一个问题我遍历thead th的时候会遍历到两份表头一份是原始表头一份是固定列克隆出来的副本。如果给克隆出来的表头也绑定了拖拽事件拖起来会非常诡异因为克隆表头的位置和原始表头并不是同步更新的。我的解决方案是在绑定事件时排除掉固定列容器$(#table thead th:not(.bs-checkbox):not(.fixed-table-fixed-left thead th))具体排除规则取决于你用的固定列插件版本。我的经验是定位到fixed-table-fixed-left这个容器里面的元素直接跳过只给原始表头绑定。6. 我的一些经验感想6.1 控制拖拽范围拖拽范围的上下限一定要根据业务场景调整。我给“日期”列设置的最小宽度是80px“渠道名称”列是100px“消耗金额”列是100px最大宽度统一限制在400px。如果完全不设限用户把“日期”列拖到只有30px整个表格的布局会被挤压得很难看。这个限制建议放在列定义里作为minWidth和maxWidth而不是写死在拖拽逻辑里{ field: cost, title: 消耗金额, width: 120, minWidth: 100, maxWidth: 300 }然后读取的时候const minW currentTh.data(minWidth) || 60; const maxW currentTh.data(maxWidth) || 500;6.2 要不要做列宽自动保存我的方案是拖拽结束时自动保存到localStorage不弹确认框不延迟保存。这样的用户体验最顺畅。但有一个隐含问题如果用户用了无痕模式或者浏览器禁止了localStorage读取和写入都会抛异常。所以要用try-catch包一层function saveColumnWidths() { try { localStorage.setItem(dashboard_table_col_widths, JSON.stringify(widths)); } catch (e) { // 隐私模式下不做持久化不影响拖拽功能 } }6.3 后续可以扩展的方向这个方案其实可以继续扩展。比如同一套表格在“运营角色”和“财务角色”看到的默认列宽不同那就在保存时带上用户ID作为key的一部分再比如用户可以一键恢复默认列宽那就在初始化之前把存储的key清掉然后重新加载表格数据。还有一个方向是让拖拽的反馈更细腻一些比如在拖拽过程中显示一条实时预览线而不是等松手了才生效。不过这个要看具体项目的视觉要求不是所有后台都需要那么精致。最后分享一个小细节别忘记在window resize时重新触发一次表格的宽度计算否则窗口缩小后表格宽度不会自动适配。$(window).on(resize, function() { $(#table).bootstrapTable(resetView); });这个调用成本很低但能避免很多用户在不同尺寸屏幕间切换时产生的布局错位问题。本文还有配套的精品资源点击获取
Bootstrap Table列宽拖拽调整与持久化实现指南
简介面向已掌握Bootstrap Table基础用法、希望提升列宽交互性的前端工程师这份压缩包提供了一整套列宽定制与拖动调整的实现方案特别适合数据管理后台、报表系统等需要灵活操作列宽的场景。资源共14个文件压缩包整体约117KB包含6个JavaScript脚本、6个CSS样式表、1个JSON数据文件和1个HTML示例页面其中bootstrap-table-colresize插件与colResizable-1.6.js负责拖动逻辑配套样式表负责界面外观。已有8414人学习下载。示例页面清晰展示了如何在表格列上通过data-width指定初始宽度并利用extensions选项启用columnResize功能让用户直接拖拽列头完成宽度调节。包内还包含Bootstrap Table主库、中文语言包及JSON示例数据整体代码结构清晰便于快速集成与本地化部署可直接作为实际项目中的参考实现节省插件接入与调试时间。 做后台管理系统这些年bootstrap table基本是我最常用的表格组件没有之一。这次接一个数据看板的重构需求需求方提了两个一开始让我觉得“这有什么难的”的要求表格列宽要能统一设置还要支持用户直接拖拽列头调整列宽。结果真正落地的时候才发现“可设置列宽和可拖动列宽”这行字背后牵扯到表格布局算法、事件绑定、数据持久化、滚动条联动一整套细节。这篇博客就把我的完整实现过程和踩坑记录分享出来给同样被这个需求折磨的同学一条可以照抄的路线。先说清楚这次项目的背景一个后台数据看板表格大概有二十多列字段包括日期、渠道、曝光量、点击率、消耗金额、转化成本、ROI等等。原来用的默认列宽字段一多屏幕根本放不下用户要看完一整行数据必须来回拖水平滚动条看左侧的维度再对比右侧的指标眼睛都快看花了。所以需求收敛成两条第一表格列宽要支持单独设置不同列不能一把尺子量到底第二用户可以直接在表头上拖拽调整列宽并且调整结果要能记住下次打开页面还是用户自己调好的样子。1. 需求复盘用户要的“可拖列宽”到底是什么1.1 数据看板场景下的宽表痛点这个项目里的表格不是简单的“展示数据”而是承载了运营同学每天的数据分析工作流。列一多问题就来了运营同学最关心的是“消耗金额”和“转化成本”这种核心指标结果这些列跟旁边的“渠道ID”列挤在一起数字被压得歪歪扭扭看的时候还得眯着眼数位数。另一个痛点是不同列的内容差异太大。“日期”列只需要十个字符的宽度“渠道名称”列可能需要二十个字符“备注”列甚至需要四十个字符。Bootstrap table默认的等宽策略显然不满足这种业务场景。用户需要的是把“日期”列压缩窄一点把“消耗金额”列拉宽让数字有呼吸感。1.2 Bootstrap table自带的宽度方案为什么不够Bootstrap table本身不是没有列宽相关的能力它提供了width属性可以给每一列指定宽度。但这里有个很坑的地方如果你用的是自适应布局表格列宽会按内容自动分配你设置的width值只能算是一个“建议值”浏览器会根据实际内容调整。更跟不上需求的是第二点拖拽调整列宽。Bootstrap table的核心库里没有现成的拖拽API你要么自己写事件逻辑要么依赖第三方插件。而且就算你实现了拖拽怎么把拖完的宽度存下来、怎么在下次渲染时恢复这些都得自己造轮子。所以这个需求的完整定义其实是指定列宽 拖拽调整 记忆持久化三者缺一不可。2. 让指定列宽真正生效布局模式与colgroup的配合2.1 为什么设置了width属性却不生效我一开始直接在columns配置里写{ field: cost, title: 消耗金额, width: 120 }刷新页面列宽纹丝不动。后来查了文档才发现Bootstrap table的宽度机制依赖两个条件一是表格要设置table-layout: fixed二是列宽要通过colgroup里的col元素来承载。如果没有固定布局浏览器会根据单元格内容自动计算宽度你在JS里配置的width值会被当成一个“最小内容宽度”的参考而不是一个确定值。这也是很多人配置了列宽却发现没生效的根因。2.2 用colgroup稳住列宽基线我最终的方案是在表格初始化之前手动生成一份colgroup配置并在columns里为每一列明确指定width。举个例子const columns [ { field: date, title: 日期, width: 100 }, { field: channel, title: 渠道, width: 130 }, { field: cost, title: 消耗金额, width: 120 } ]; // 初始化时把 width 写进 colgroup $(#table).bootstrapTable({ columns: columns, // 这两行是关键 tableWidth: 100%, // 通过这张表设置 });有人可能会问为什么不能直接设置width属性就行这里要解释一下Bootstrap table的内部机制初始化时它会根据columns的配置动态生成HTML表格结构包括colgroup和thead。如果你在列定义中设置了width它会生成对应的col stylewidth: 120px;。但如果你用onLoadSuccess之类的回调去动态修改列头就有可能导致colgroup没有同步更新出现“表头宽度变了内容列宽没变”的错位。所以我的建议是列宽的基线配置最好在初始化时就定好不要指望后期靠CSS修补。2.3 列宽参数的持久化策略第二个需求的“记忆功能”我用的是localStorage。用户拖完列宽之后把每一列的字段名和宽度值组成一个对象存起来function saveColumnWidths() { const widths {}; columns.forEach(col { const $headerCell $(#table thead th[data-field${col.field}]); widths[col.field] $headerCell.outerWidth(); }); localStorage.setItem(dashboard_table_col_widths, JSON.stringify(widths)); }下次进入页面时在列定义里做一次合并覆盖const saved JSON.parse(localStorage.getItem(dashboard_table_col_widths) || {}); const columns baseColumns.map(col { if (saved[col.field]) { col.width saved[col.field]; } return col; });之所以用outerWidth而不是直接读style.width是因为边框和padding会影响实际渲染宽度outerWidth取到的才是用户肉眼看到的那条线。3. 拖拽列宽的两条技术路线我为什么选了手写3.1 现成插件方案bootstrap-table-resizable与colresizable社区里其实有现成的方案最常用的是bootstrap-table-resizable它底层依赖colresizable这个jQuery插件。接入方式也简单把两个文件引入页面然后在表格配置里加一行resizable: true就能用了。我一开始也确实试了这个方案。但我遇到了几个问题第一它在某些版本下跟fixedColumns固定列插件配合得不太好左侧固定列会挡住拖拽手柄第二默认的拖拽范围没有限制用户可以把一列拖到几乎消失或者拖到把整个表格撑爆第三也是最重要的它拖拽后的宽度变化不会主动通知你要拿到最新的列宽数据需要额外写监听逻辑反而麻烦了。3.2 手写拖拽的代价与收益权衡了一下我决定自己写拖拽逻辑。手写的好处是每个行为都在自己掌控里拖拽手柄的样式可以自定义宽度范围可以做上下限限制拖拽过程中可以实时回馈拖完之后的同步逻辑也是自己说了算。代价当然也有需要理解表格布局的底层机制处理各种边缘情况还要兼容Bootstrap table动态渲染表格节点的时间点。但这个代价是值得的因为一旦自己掌握了这套逻辑后续做列宽的默认配置、按角色保存、按页面保存都变得很容易。插件很多时候是个黑盒黑盒里出了问题你只能干瞪眼。4. 手写列宽拖拽的核心实现从事件捕获到列宽同步4.1 给表头单元格装拖拽手柄Bootstrap table渲染完成后thead里的每个th就是我们的操作目标。我选择在每个th的右侧添加一个绝对定位的拖拽手柄这里有个小细节手柄不是放在th内部而是放在th的::after伪元素或一个独立span上。我的做法是在表格加载完成后遍历所有表头单元格插入一个span classresize-handlefunction addResizeHandles() { $(#table thead th).each(function() { // 避免重复插入 if ($(this).find(.resize-handle).length) return; $(this).append(span classresize-handle/span); }); }CSS部分.resize-handle { position: absolute; right: 0; top: 0; width: 6px; height: 100%; cursor: col-resize; z-index: 10; background: transparent; } .resize-handle:hover { background: rgba(0, 0, 0, 0.1); }注意th的position必须是relative否则手柄的absolute定位会找到更外层的容器去。我在这个坑里浪费了十分钟。4.2 mousedown、mousemove、mouseup三件套拖拽的核心逻辑是三段式mousedown时记录起始坐标和起始列宽mousemove时计算位移差值并更新列宽mouseup时解除事件绑定并触发保存。let isResizing false; let currentTh null; let startX 0; let startWidth 0; $(#table).on(mousedown, .resize-handle, function(e) { e.preventDefault(); isResizing true; currentTh $(this).closest(th); startX e.pageX; startWidth currentTh.outerWidth(); $(document).on(mousemove, onMouseMove); $(document).on(mouseup, onMouseUp); }); function onMouseMove(e) { if (!isResizing) return; const diff e.pageX - startX; let newWidth startWidth diff; // 宽度限制 if (newWidth 60) newWidth 60; if (newWidth 400) newWidth 400; currentTh.css(width, newWidth px); // 同步对应的 col 元素 const index currentTh.index(); $(#table colgroup col).eq(index).css(width, newWidth px); } function onMouseUp() { isResizing false; currentTh null; $(document).off(mousemove, onMouseMove); $(document).off(mouseup, onMouseUp); saveColumnWidths(); }这里有个很关键的细节e.preventDefault()一定要写否则拖拽过程中浏览器会默认选中表格中的文本导致屏幕上出现一片蓝色选区特别难看。另一个细节是为什么更新th之后还要同步更新colgroup。因为表格的列宽实际上是由colgroup里的col元素控制的th的宽度更多是展示层面的。如果你只改了th表格内容的td不会跟着变就会出现“表头拉宽了内容还是老样子”的撕裂效果。4.3 拖拽结束后同步回Bootstrap table的数据状态上面代码里每次mousemove都在更新DOM但Bootstrap table内部还有一份列宽的状态这个状态如果不更新下次你调用getOptions()拿到的列宽配置还是旧的对后续开发是个隐患。我的做法是在mouseup之后手动遍历一次列配置更新optionsfunction syncOptions() { const options $(#table).bootstrapTable(getOptions); options.columns[0].forEach(col { const $headerCell $(#table thead th[data-field${col.field}]); if ($headerCell.length) { col.width $headerCell.outerWidth(); } }); }需要注意options.columns是个二维数组因为Bootstrap table支持行分组和多个thead层级第一层columns[0]对应最外层表头。如果你的表头没有分组那columns[0]就是所有列。5. 我在实际项目中踩过的坑5.1 拖拽列宽后表头与表格内容错位第一次实现完拖拽后我遇到一个很奇怪的现象表头被拉宽了但对应列的内容还是窄的整张表格看起来像被错位扯了一下。排查后发现问题出在Bootstrap table的渲染机制上。它的表头和数据部分是分两个独立模块渲染的如果你给某一个th直接设置了宽度而colgroup里对应的col没有同步调整浏览器会根据col的宽度去渲染数据行。所以解决方案就是我上面代码里写的拖拽时不仅改th还要改colgroup里对应的col。第二次踩坑是初始化时设置了colWidths: [100, 200, 150]这种方式。Bootstrap table对纯数字数组的解析有时会失效尤其在widthUnit配置了百分比的情况下。我建议列宽宽度一律显式写成像素值别写百分比拖拽计算时会简单很多。5.2 表格存在水平滚动条时拖拽断触我们的看板表格列数多在1280px的屏幕上肯定会溢出于是出现了水平滚动条。这时拖拽右侧列的宽度就会出现一个极其烦人的问题拖拽过程中只要鼠标移到表格边界页面就会自动产生滚动导致pageX的位置一直在跳拖拽手柄跟手程度很差。这个事一开始我以为是代码问题后来发现是拖拽事件和滚动容器的事件发生了竞争。解决方案是在拖拽开始时给body加一个overflow: hidden的类拖拽结束后再移除function onMouseMove(e) { // ... document.body.style.overflow hidden; } function onMouseUp() { // ... document.body.style.overflow ; }但不推荐在每个mousemove里都做这个操作会有性能损耗我只在开始拖拽的第一次mousemove时加一次。5.3 与固定列、批量操作列的冲突表格的左侧有两个固定列一个是序号一个是复选框列用来做批量操作。Bootstrap table的固定列原理是把固定列复制出来单独渲染然后用绝对定位盖在表格上方。这就导致了一个问题我遍历thead th的时候会遍历到两份表头一份是原始表头一份是固定列克隆出来的副本。如果给克隆出来的表头也绑定了拖拽事件拖起来会非常诡异因为克隆表头的位置和原始表头并不是同步更新的。我的解决方案是在绑定事件时排除掉固定列容器$(#table thead th:not(.bs-checkbox):not(.fixed-table-fixed-left thead th))具体排除规则取决于你用的固定列插件版本。我的经验是定位到fixed-table-fixed-left这个容器里面的元素直接跳过只给原始表头绑定。6. 我的一些经验感想6.1 控制拖拽范围拖拽范围的上下限一定要根据业务场景调整。我给“日期”列设置的最小宽度是80px“渠道名称”列是100px“消耗金额”列是100px最大宽度统一限制在400px。如果完全不设限用户把“日期”列拖到只有30px整个表格的布局会被挤压得很难看。这个限制建议放在列定义里作为minWidth和maxWidth而不是写死在拖拽逻辑里{ field: cost, title: 消耗金额, width: 120, minWidth: 100, maxWidth: 300 }然后读取的时候const minW currentTh.data(minWidth) || 60; const maxW currentTh.data(maxWidth) || 500;6.2 要不要做列宽自动保存我的方案是拖拽结束时自动保存到localStorage不弹确认框不延迟保存。这样的用户体验最顺畅。但有一个隐含问题如果用户用了无痕模式或者浏览器禁止了localStorage读取和写入都会抛异常。所以要用try-catch包一层function saveColumnWidths() { try { localStorage.setItem(dashboard_table_col_widths, JSON.stringify(widths)); } catch (e) { // 隐私模式下不做持久化不影响拖拽功能 } }6.3 后续可以扩展的方向这个方案其实可以继续扩展。比如同一套表格在“运营角色”和“财务角色”看到的默认列宽不同那就在保存时带上用户ID作为key的一部分再比如用户可以一键恢复默认列宽那就在初始化之前把存储的key清掉然后重新加载表格数据。还有一个方向是让拖拽的反馈更细腻一些比如在拖拽过程中显示一条实时预览线而不是等松手了才生效。不过这个要看具体项目的视觉要求不是所有后台都需要那么精致。最后分享一个小细节别忘记在window resize时重新触发一次表格的宽度计算否则窗口缩小后表格宽度不会自动适配。$(window).on(resize, function() { $(#table).bootstrapTable(resetView); });这个调用成本很低但能避免很多用户在不同尺寸屏幕间切换时产生的布局错位问题。本文还有配套的精品资源点击获取 
