jQuery 表格操作这件事第一篇里我把最基础的取行、取列、取值过了一遍当时就有读者留言问动态加了一行之后原来绑在按钮上的点击事件怎么全废了还有人说表格数据一多翻页卡得像幻灯片。这些问题在第一篇里没展开因为它们已经不是怎么选到元素的层面而是牵扯到事件模型、数据同步和渲染性能。这篇就专门把这些坑一个一个挖出来。先给个定位这篇聊的是jQuery Table 的行级操作进阶包括动态增删改行、表格数据和 DOM 的双向同步、事件委托、排序筛选分页的前端实现以及千行级表格的性能处理。适合已经能用 jQuery 选到表格、但一遇到动态生成和数据量大就卡壳的同学如果你在做后台管理系统、配置页、订单列表这类典型的表格密集型页面这篇里的代码基本可以直接拿去改。所有示例都基于 jQuery 3.x1.x 的写法差异我会在相应位置标注。1. 先想清楚一件事表格到底是数据还是 DOM1.1 两种心智模型决定了你后面所有的写法这是我看过最多人栽跟头的地方。写表格代码之前脑子里必须先选定一种模型否则代码会越写越乱。DOM 优先模型表格就是页面上的那些tr数据在 DOM 里你要什么就从 DOM 里读什么。适合静态表格、行数很少、几乎没有交互的场景。优点是直观写完就能跑缺点是数据一多就完蛋而且任何数据变了但 DOM 没变的情况都会引发 bug。数据优先模型数组或对象数组才是数据的唯一真相DOM 只是这个数组的一次渲染结果。任何增删改都先改数组然后重新渲染或只渲染变化的部分。适合后台列表页、需要排序筛选分页、需要提交给后端的场景。我在实际项目里的判断标准很粗暴这张表需要提交给后端吗需要排序筛选吗行数会超过 100 吗三个里中一个就别犹豫走数据优先。提示不要一半一半。最怕的是数据从后端拿了一份存在数组里用户编辑的时候又直接改 DOM。等到提交的时候你还得从 DOM 反向扒一遍这时候输入框里的值、复选框的选中态、下拉框的选中项三种元素三种取值方式扒漏一个就是线上事故。1.2 数据优先模型的最小骨架不用上框架jQuery 加一个数组就够。核心就三个函数渲染、增删改、取数。var tableData []; // 唯一数据源 // 渲染把数组变成 tbody function renderTable(list) { var html ; for (var i 0; i list.length; i) { var row list[i]; html tr>function escapeHtml(str) { return String(str null ? : str) .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;); }这套骨架的好处是删除一行就是tableData.splice(index, 1)然后重新渲染新增一行就是tableData.push(obj)然后重新渲染。逻辑永远只有一条链路出问题的时候你只需要检查数组对不对和渲染函数有没有毛病排查范围直接砍掉一大半。2. 动态增删改行写法很多能用的没几个2.1 新增行的三种写法与适用边界写法一字符串拼接 html()$(#dataTable tbody).append(trtd id /tdtd name /td/tr);短平快但有两个硬伤。一是append单次调用会触发一次重排循环里连着 append 五十行浏览器就得算五十遍布局二是拼字符串的时候属性里的引号特别容易出问题name里带个双引号你的>var $tr $(tr).attr(data-id, row.id); $tr.append($(td).text(row.id)); $tr.append($(td).text(row.name)); $(#dataTable tbody).append($tr);.text()自动做了 HTML 转义比字符串拼接安全得多。缺点还是那个每 append 一次就是一次 DOM 操作。少量行没问题批量插入就慢。写法三批量拼串 一次性 html()var html ; for (var i 0; i batch.length; i) { html tr>$(#dataTable).on(click, .btn-del, function () { var $tr $(this).closest(tr); var id $tr.attr(data-id); if (!confirm(确定删除这一行)) return; // 同步数据源 tableData tableData.filter(function (item) { return String(item.id) ! String(id); }); // 重新渲染 renderTable(tableData); });closest(tr)比parent().parent()稳得多。表格稍微加点嵌套比如单元格里包了个 divparent().parent()就选错层了这种 bug 我见过不止一次表现是删了一行结果删错了一行排查起来特别恶心。批量删除就有坑了。很多人这么写// 错误示范 $(.row-checkbox:checked).each(function () { $(this).closest(tr).remove(); });在 jQuery 的each里删 DOM 一般不会报错因为它遍历的是 jQuery 内部集合的快照但如果在里面同时又调用了tableData.splice(i, 1)索引就全乱了——删掉数组第 0 项之后原来的第 1 项变成了第 0 项循环却已经走到了 i1等于漏删一个。批量删的正确姿势是倒序遍历或者先收集再过滤// 方式一收集 id然后过滤数据源重渲染 var ids $(.row-checkbox:checked).map(function () { return $(this).closest(tr).attr(data-id); }).get(); tableData tableData.filter(function (item) { return ids.indexOf(String(item.id)) -1; }); renderTable(tableData);这段代码还有个隐性好处因为走的是过滤数据源 整体重渲染你完全不用管 DOM 是怎么删的也就不存在索引错乱的问题。2.3 行内编辑原地编辑的三个注意事项原地编辑点一下单元格变成输入框体验很好但实现上有三个点容易翻车。第一编辑状态要保住。如果你在单元格上html(input)失焦时读值再写回去中间用户点了别的地方触发了重渲染输入的内容就没了。我的做法是编辑期间不重渲染整表只在当前单元格内做替换。$(#dataTable).on(click, td.editable, function () { var $td $(this); if ($td.find(input).length) return; // 已经在编辑别重复插入 var oldVal $td.text(); var $input $(input typetext).val(oldVal); $td.empty().append($input); $input.trigger(focus).trigger(select); $input.on(blur, function () { var newVal $.trim($input.val()); if (newVal ! oldVal) { var id $td.closest(tr).attr(data-id); var field $td.attr(data-field); // 哪一列靠>$input.on(keydown, function (e) { if (e.keyCode 13) { $input.trigger(blur); } if (e.keyCode 27) { $input.val(oldVal); $input.trigger(blur); } });第三blur 和 click 的顺序。这是个经典陷阱用户在编辑状态下直接点了保存按钮blur 会先触发但保存函数可能拿到的是改之前的值。解决办法是在保存前主动$(:focus).trigger(blur)或者干脆用mousedown代替click来处理保存。3. 表格数据的双向同步从 DOM 里把数据抠出来3.1 表格转 JSON一行一对象的标准实现有时候表格是后端直出的 HTML服务端渲染前端需要把它变成 JSON 提交或者导出。这个功能我在三四个老项目里都写过套路固定function tableToJson($table) { var headers []; // 优先取 thead 的文本跳过隐藏列 $table.find(thead tr).first().find(th).each(function () { headers.push($(this).attr(data-field) || $.trim($(this).text())); }); var result []; $table.find(tbody tr).each(function () { if ($(this).hasClass(row-empty) || $(this).hasClass(row-loading)) return; // 过滤占位行 var obj {}; $(this).find(td).each(function (i) { var $td $(this); if ($td.attr(colspan)) return; // 合并单元格跳过单独处理 obj[headers[i]] $.trim($td.text()); }); result.push(obj); }); return result; }这段代码里有两个防御性判断过滤占位行很多表格会在无数据时插一行暂无数据不过滤就会被当成真实数据提交、跳过 colspan 单元格。前者是我真的被坑过——空表格提交时后端收到一条{name: 暂无数据}的记录。3.2 单元格里有表单元素时怎么取值纯文本单元格直接.text()就行但一旦单元格里塞了 checkbox、select、radio取值方式完全不同。这张表列一下免得每次都要去翻元素类型正确取值常见错误写法错误表现文本框$td.find(input).val()$td.text()永远拿到空字符串复选框$cb.prop(checked)$cb.attr(checked)取消勾选后依然返回 checked下拉框$sel.val()$sel.attr(value)拿到初始值不是当前选中值单选组$td.find(input:radio:checked).val()$td.find(input:radio).val()永远返回第一个的值隐藏域$el.val()$el.text()空字符串关于attr和prop的区别值得展开一句attr读的是 HTML 标签上写的初始属性prop读的是 DOM 对象的当前状态。用户点了复选框之后改变的只是checked这个 propertyHTML 标签上的checkedchecked属性压根没变。所以凡是涉及状态的checked、selected、disabled一律用prop凡是涉及自定义数据的data-*、title、自定义属性用attr。3.3 什么该放>$(#dataTable).on(click, .btn-del, function () { // 这里的 this 是被点击的那个按钮 });原理是点击按钮 → 事件冒泡到#dataTable→ jQuery 检查事件源是否匹配.btn-del→ 匹配就执行且把this指向匹配元素。因为监听挂在父元素上父元素一直存在后面渲染多少行都能被接住。选择器精度这里有个细节很多人写委托时选择器写得太宽// 反例选择器太宽容易误伤 $(#dataTable).on(click, button, function () { /* 删除逻辑 */ });表格里以后要是加了个查看详情按钮也会命中这条规则然后被当成删除执行。选择器必须写到能唯一标识行为用 class 而不是标签名$(#dataTable).on(click, .btn-del, function () { ... }); $(#dataTable).on(click, .btn-edit, function () { ... });另一个常见问题是委托写在document上// 不推荐除非确实需要 $(document).on(click, .btn-del, function () { ... });能用但缺点明显页面上任何一次点击都要冒泡到 document 才判断事件链最长而且如果页面上有多张表格选择器可能误伤别的表。委托的落点原则是离目标最近的、且在绑定时就已存在的父元素通常就是#dataTable或者tbody。4.3 委托里拿不到正确 this 的两种情况第一种是用了箭头函数。jQuery 委托依赖this的动态绑定箭头函数会把this锁死在定义时的作用域拿到的是 window 或者外层对象。写 ES5 的function就对了。第二种是在委托回调里又套了一层each或者setTimeout里面再用this就变了$(#dataTable).on(click, .btn-del, function () { var $btn $(this); // 先缓存 setTimeout(function () { $btn.closest(tr).remove(); // 这里不能用 this }, 300); });养成委托回调第一行先var $this $(this)的习惯能省掉大量莫名其妙的 bug。提示委托还有个附赠好处。用.on()委托绑定的事件元素被 remove 之后不会造成内存泄漏而直接绑在元素上的事件如果元素被移除但没解绑在老版本 IE 上会有泄漏风险。这也是为什么表格这类高频增删的场景我强烈建议全用委托。5. 排序、筛选、分页前端三件套的最小实现5.1 排序别在 DOM 上动刀用 jQuery 直接操作 DOM 排序是可行的.detach()收集再按序 append但代码又长又容易出错尤其是带合并单元格或者隔行变色的时候。数据优先模型的排序只有三步function sortTable(key, desc) { tableData.sort(function (a, b) { var va a[key], vb b[key]; // 数字按数值排字符串按本地化规则排 if (typeof va number typeof vb number) { return desc ? vb - va : va - vb; } return desc ? String(vb).localeCompare(String(va), zh-CN) : String(va).localeCompare(String(vb), zh-CN); }); renderTable(tableData); }两个细节值得说。一是localeCompare的第二个参数中文排序不加zh-CN会按 Unicode 码点排结果跟人的直觉完全不符阿会跑到张后面。二是数字和字符串要分开处理10 - 9的结果是 1因为减法会隐式转数字但10 9是 true字符串比较逐字符比。见过用比较数字字符串写排序的结果 10 排在 9 前面找半天。带箭头指示的表头切换也很简单用一个状态变量记当前排序列和方向var sortState { key: id, desc: false }; $(#dataTable).on(click, th.sortable, function () { var key $(this).attr(data-field); sortState.desc (sortState.key key) ? !sortState.desc : false; sortState.key key; sortTable(key, sortState.desc); // 更新箭头 $(th.sortable).removeClass(asc desc); $(this).addClass(sortState.desc ? desc : asc); });5.2 筛选过滤数组不是隐藏行$(tr).hide()这种筛选在行数少的时候能跑但会有一个致命问题筛选状态下做分页或者做全选你会把这些隐藏行的状态也带进去。正确做法还是过滤数组用一个viewData表示当前视图数据var allData []; // 全量 var viewData []; // 当前视图筛选排序后 function applyFilter(keyword) { keyword $.trim(keyword).toLowerCase(); viewData !keyword ? allData.slice() : allData.filter(function (item) { return String(item.name).toLowerCase().indexOf(keyword) -1 || String(item.id).indexOf(keyword) -1; }); currentPage 1; // 筛选后必须回到第一页 renderPage(); }currentPage 1这行不能漏。用户在第五页输入筛选词结果筛出来只有 3 条数据一共 1 页你还停在第 5 页表格就是一片空白用户以为筛选坏了。5.3 分页切片渲染不要把全量塞进 DOMvar pageSize 10; var currentPage 1; function renderPage() { var start (currentPage - 1) * pageSize; var pageList viewData.slice(start, start pageSize); renderTable(pageList); renderPager(viewData.length, currentPage, pageSize); } function renderPager(total, page, size) { var totalPage Math.ceil(total / size) || 1; var html ; html button classpg-prev (page 1 ? disabled : ) 上一页/button; html span page / totalPage 共 total 条/span; html button classpg-next (page totalPage ? disabled : ) 下一页/button; $(#pager).html(html); }分页这套逻辑里最容易错的是边界值总数 0 时totalPage算出来是 0页码显示 1 / 0 就很怪所以加|| 1。还有删除最后一页最后一条数据之后currentPage超过了totalPage页面上什么都没有得补一句校正var totalPage Math.ceil(viewData.length / pageSize) || 1; if (currentPage totalPage) currentPage totalPage;6. 千行表格不卡的关键渲染性能三板斧6.1 第一板斧批量操作减少 DOM 调用次数浏览器渲染的成本主要在重排reflow和重绘repaint。每一次append、css修改、text修改只要影响了布局就可能触发一次重排。循环里做 1000 次就是 1000 次重排不掉帧才怪。对比一下实测数据Chrome1000 行 × 5 列渲染方式耗时约说明循环append($tr)800~1200ms每行一次 DOM 插入重排累积循环append(htmlString)300~500ms每次仍是独立插入字符串解析有开销拼串 一次html()40~80ms一次解析一次插入重排只有一轮DocumentFragment30~60ms与拼串接近但内存占用略低结论很明确批量场景一律走拼串 一次 html()。注意html()是整体替换如果表格里已经有内容且你只想追加用append(htmlString)同样是单次插入效果差不多。用 DocumentFragment 的写法也贴一下适合需要 jQuery 对象操作比如批量绑属性的场景var frag document.createDocumentFragment(); for (var i 0; i list.length; i) { var tr document.createElement(tr); tr.setAttribute(data-id, list[i].id); tr.innerHTML td list[i].id /tdtd escapeHtml(list[i].name) /td; frag.appendChild(tr); } $(#dataTable tbody).empty().append(frag);6.2 第二板斧避开布局抖动有个隐蔽的性能杀手叫读写交替。这段代码看着没问题实际上每次循环都在强制浏览器同步计算布局// 慢读写交替 for (var i 0; i rows.length; i) { var h $(rows[i]).height(); // 读触发布局计算 $(rows[i]).css(line-height, h px); // 写让布局失效 }正确的做法是先读后写把所有的读集中在一起写集中在一起var heights []; for (var i 0; i rows.length; i) { heights.push($(rows[i]).height()); } for (var j 0; j rows.length; j) { $(rows[j]).css(line-height, heights[j] px); }这条原则在表格里最常见的场景就是让所有行的行高与内容最高的那一行对齐务必先收集高度再统一设置。6.3 第三板斧超过一定行数该考虑虚拟滚动了拼串 一次插入能把 1000 行压到 80ms 左右但 5000 行的时候就是 400ms 起步而且 DOM 节点太多滚动起来也发顿。这时候有两条路。一条是上插件用别人的成熟方案省事一条是自己写虚拟滚动原理不复杂外层容器固定高度overflow: auto内层放一个占位元素高度 总行数 × 单行高度滚动时算出当前可视区域对应哪几行只渲染这几行加前后各 10 行的缓冲用transform: translateY()或者padding-top把渲染出的行推到正确位置。var rowHeight 36; var buffer 10; $(#scrollBox).on(scroll, function () { var scrollTop this.scrollTop; var start Math.max(0, Math.floor(scrollTop / rowHeight) - buffer); var end start Math.ceil(this.clientHeight / rowHeight) buffer * 2; var slice viewData.slice(start, end); renderRows(slice, start); // 内部用 translateY 定位 });滚动事件记得节流不然每一像素的滚动都触发一次渲染var timer null; $(#scrollBox).on(scroll, function () { clearTimeout(timer); var self this; timer setTimeout(function () { doRender(self); }, 16); });提示行数超过 2000 且需要排序、筛选、编辑的表格我的建议是别再自己造轮子了。自己写的虚拟滚动在遇到行高不一致比如单元格内容换行时会变得非常难受因为高度是动态的位置推算全得重来。这种场景直接选一个成熟表格组件把精力留给业务逻辑更划算。7. 那些反复踩的坑一份速查表7.1 常见问题的现象、成因与解法现象大概率成因排查动作解决动态加入的按钮点击无反应事件绑定时元素不存在检查绑定代码位置改用事件委托删除后删错了行用了parent().parent()或索引错位打印被删行的>// 稳 var name $tr.find(td[data-fieldname]).text(); // 不稳合并单元格后必错 var name $tr.find(td).eq(1).text();三是:checked选择器在大量元素上很慢。表格有 2000 行每行一个复选框你写$(input:checked)jQuery 会遍历所有 input 逐个判断。改写成$(input[typecheckbox]).filter(:checked)或者干脆自己维护一个选中 id 的 Set性能差距在千行级别上很明显。var selectedIds {}; // 用对象做 Set兼容性好 $(#dataTable).on(change, .row-checkbox, function () { var id $(this).closest(tr).attr(data-id); if (this.checked) { selectedIds[id] true; } else { delete selectedIds[id]; } updateSelectedCount(); });这种自己维护选中集合的做法还有个额外好处分页切换、重新渲染之后选中状态依然在不会因为 DOM 重建而丢失。这一点在批量操作的后台页面里是刚需用户翻了三页勾了一堆东西结果一翻页全没了体验会非常差。8. 一些实操中总结出来的小技巧最后这几段不讲体系纯讲我这些年攒下来的一些顺手的小招。用事件命名空间管理多套监听。表格上的事件一多容易互相干扰。给事件加命名空间解绑的时候可以精确打击$(#dataTable).on(click.tblSort, th.sortable, fn1); $(#dataTable).on(click.tblDel, .btn-del, fn2); // 只解绑排序相关的 $(#dataTable).off(click.tblSort);框架切换时记得清空。$(#dataTable tbody).empty()比.html()略快一点点而且语义更清楚。但要注意empty()会一并清掉绑在子元素上的数据和事件如果你在行上存了.data()需要先清理再 empty否则有内存泄漏隐患。用事件委托的话这个问题基本不存在这也是我一直推荐委托的原因之一。加一个无数据占位行但别让它参与计算。表格数据为空时显示一行暂无数据视觉上必要。但一定要给它加一个特殊 class比如row-empty并且在所有涉及行遍历的函数里排除掉它——行数统计、表格转 JSON、全选逻辑全都要排除。我见过全选把暂无数据这行也勾上的非常尴尬。样式尽量用 CSS别用 jQuery 去改。$tr.css(background, #f5f5f5)这种写法在动态渲染之后就会丢失因为新渲染的行没有这个内联样式。悬停高亮、斑马纹、选中态这些全部写成 CSS 类渲染时根据数据打上对应的 class稳定可靠。#dataTable tbody tr:hover { background: #f5f7fa; } #dataTable tbody tr.is-selected { background: #e8f0fe; }接口返回的数据先洗一遍再进数组。后端给的字段类型经常不统一id 有时候是数字有时候是字符串排序和比对的时候就会出问题。统一做一次转换所有 id 转字符串所有数量字段转数字时间字段统一格式。这一步花不了几分钟能省掉后面无数个为什么这条匹配不上的排查。我个人在实际项目里的体会是jQuery 操作表格本身没什么难的难的是先把数据模型定死然后所有操作都收敛到这一条链路上。只要坚持改数据 → 重渲染这个单向流代码写到几千行也乱不了一旦允许这里顺手改一下 DOM三个月后你自己都不敢动那张表。至于性能绝大多数后台页面在分页 拼串渲染的组合下就完全够用了真到了需要虚拟滚动的量级那说明业务已经长到该换技术方案的时候了。
jQuery 表格操作这件事第一篇里我把最基础的取行、取列、取值过了一遍当时就有读者留言问动态加了一行之后原来绑在按钮上的点击事件怎么全废了还有人说表格数据一多翻页卡得像幻灯片。这些问题在第一篇里没展开因为它们已经不是怎么选到元素的层面而是牵扯到事件模型、数据同步和渲染性能。这篇就专门把这些坑一个一个挖出来。先给个定位这篇聊的是jQuery Table 的行级操作进阶包括动态增删改行、表格数据和 DOM 的双向同步、事件委托、排序筛选分页的前端实现以及千行级表格的性能处理。适合已经能用 jQuery 选到表格、但一遇到动态生成和数据量大就卡壳的同学如果你在做后台管理系统、配置页、订单列表这类典型的表格密集型页面这篇里的代码基本可以直接拿去改。所有示例都基于 jQuery 3.x1.x 的写法差异我会在相应位置标注。1. 先想清楚一件事表格到底是数据还是 DOM1.1 两种心智模型决定了你后面所有的写法这是我看过最多人栽跟头的地方。写表格代码之前脑子里必须先选定一种模型否则代码会越写越乱。DOM 优先模型表格就是页面上的那些tr数据在 DOM 里你要什么就从 DOM 里读什么。适合静态表格、行数很少、几乎没有交互的场景。优点是直观写完就能跑缺点是数据一多就完蛋而且任何数据变了但 DOM 没变的情况都会引发 bug。数据优先模型数组或对象数组才是数据的唯一真相DOM 只是这个数组的一次渲染结果。任何增删改都先改数组然后重新渲染或只渲染变化的部分。适合后台列表页、需要排序筛选分页、需要提交给后端的场景。我在实际项目里的判断标准很粗暴这张表需要提交给后端吗需要排序筛选吗行数会超过 100 吗三个里中一个就别犹豫走数据优先。提示不要一半一半。最怕的是数据从后端拿了一份存在数组里用户编辑的时候又直接改 DOM。等到提交的时候你还得从 DOM 反向扒一遍这时候输入框里的值、复选框的选中态、下拉框的选中项三种元素三种取值方式扒漏一个就是线上事故。1.2 数据优先模型的最小骨架不用上框架jQuery 加一个数组就够。核心就三个函数渲染、增删改、取数。var tableData []; // 唯一数据源 // 渲染把数组变成 tbody function renderTable(list) { var html ; for (var i 0; i list.length; i) { var row list[i]; html tr>function escapeHtml(str) { return String(str null ? : str) .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;); }这套骨架的好处是删除一行就是tableData.splice(index, 1)然后重新渲染新增一行就是tableData.push(obj)然后重新渲染。逻辑永远只有一条链路出问题的时候你只需要检查数组对不对和渲染函数有没有毛病排查范围直接砍掉一大半。2. 动态增删改行写法很多能用的没几个2.1 新增行的三种写法与适用边界写法一字符串拼接 html()$(#dataTable tbody).append(trtd id /tdtd name /td/tr);短平快但有两个硬伤。一是append单次调用会触发一次重排循环里连着 append 五十行浏览器就得算五十遍布局二是拼字符串的时候属性里的引号特别容易出问题name里带个双引号你的>var $tr $(tr).attr(data-id, row.id); $tr.append($(td).text(row.id)); $tr.append($(td).text(row.name)); $(#dataTable tbody).append($tr);.text()自动做了 HTML 转义比字符串拼接安全得多。缺点还是那个每 append 一次就是一次 DOM 操作。少量行没问题批量插入就慢。写法三批量拼串 一次性 html()var html ; for (var i 0; i batch.length; i) { html tr>$(#dataTable).on(click, .btn-del, function () { var $tr $(this).closest(tr); var id $tr.attr(data-id); if (!confirm(确定删除这一行)) return; // 同步数据源 tableData tableData.filter(function (item) { return String(item.id) ! String(id); }); // 重新渲染 renderTable(tableData); });closest(tr)比parent().parent()稳得多。表格稍微加点嵌套比如单元格里包了个 divparent().parent()就选错层了这种 bug 我见过不止一次表现是删了一行结果删错了一行排查起来特别恶心。批量删除就有坑了。很多人这么写// 错误示范 $(.row-checkbox:checked).each(function () { $(this).closest(tr).remove(); });在 jQuery 的each里删 DOM 一般不会报错因为它遍历的是 jQuery 内部集合的快照但如果在里面同时又调用了tableData.splice(i, 1)索引就全乱了——删掉数组第 0 项之后原来的第 1 项变成了第 0 项循环却已经走到了 i1等于漏删一个。批量删的正确姿势是倒序遍历或者先收集再过滤// 方式一收集 id然后过滤数据源重渲染 var ids $(.row-checkbox:checked).map(function () { return $(this).closest(tr).attr(data-id); }).get(); tableData tableData.filter(function (item) { return ids.indexOf(String(item.id)) -1; }); renderTable(tableData);这段代码还有个隐性好处因为走的是过滤数据源 整体重渲染你完全不用管 DOM 是怎么删的也就不存在索引错乱的问题。2.3 行内编辑原地编辑的三个注意事项原地编辑点一下单元格变成输入框体验很好但实现上有三个点容易翻车。第一编辑状态要保住。如果你在单元格上html(input)失焦时读值再写回去中间用户点了别的地方触发了重渲染输入的内容就没了。我的做法是编辑期间不重渲染整表只在当前单元格内做替换。$(#dataTable).on(click, td.editable, function () { var $td $(this); if ($td.find(input).length) return; // 已经在编辑别重复插入 var oldVal $td.text(); var $input $(input typetext).val(oldVal); $td.empty().append($input); $input.trigger(focus).trigger(select); $input.on(blur, function () { var newVal $.trim($input.val()); if (newVal ! oldVal) { var id $td.closest(tr).attr(data-id); var field $td.attr(data-field); // 哪一列靠>$input.on(keydown, function (e) { if (e.keyCode 13) { $input.trigger(blur); } if (e.keyCode 27) { $input.val(oldVal); $input.trigger(blur); } });第三blur 和 click 的顺序。这是个经典陷阱用户在编辑状态下直接点了保存按钮blur 会先触发但保存函数可能拿到的是改之前的值。解决办法是在保存前主动$(:focus).trigger(blur)或者干脆用mousedown代替click来处理保存。3. 表格数据的双向同步从 DOM 里把数据抠出来3.1 表格转 JSON一行一对象的标准实现有时候表格是后端直出的 HTML服务端渲染前端需要把它变成 JSON 提交或者导出。这个功能我在三四个老项目里都写过套路固定function tableToJson($table) { var headers []; // 优先取 thead 的文本跳过隐藏列 $table.find(thead tr).first().find(th).each(function () { headers.push($(this).attr(data-field) || $.trim($(this).text())); }); var result []; $table.find(tbody tr).each(function () { if ($(this).hasClass(row-empty) || $(this).hasClass(row-loading)) return; // 过滤占位行 var obj {}; $(this).find(td).each(function (i) { var $td $(this); if ($td.attr(colspan)) return; // 合并单元格跳过单独处理 obj[headers[i]] $.trim($td.text()); }); result.push(obj); }); return result; }这段代码里有两个防御性判断过滤占位行很多表格会在无数据时插一行暂无数据不过滤就会被当成真实数据提交、跳过 colspan 单元格。前者是我真的被坑过——空表格提交时后端收到一条{name: 暂无数据}的记录。3.2 单元格里有表单元素时怎么取值纯文本单元格直接.text()就行但一旦单元格里塞了 checkbox、select、radio取值方式完全不同。这张表列一下免得每次都要去翻元素类型正确取值常见错误写法错误表现文本框$td.find(input).val()$td.text()永远拿到空字符串复选框$cb.prop(checked)$cb.attr(checked)取消勾选后依然返回 checked下拉框$sel.val()$sel.attr(value)拿到初始值不是当前选中值单选组$td.find(input:radio:checked).val()$td.find(input:radio).val()永远返回第一个的值隐藏域$el.val()$el.text()空字符串关于attr和prop的区别值得展开一句attr读的是 HTML 标签上写的初始属性prop读的是 DOM 对象的当前状态。用户点了复选框之后改变的只是checked这个 propertyHTML 标签上的checkedchecked属性压根没变。所以凡是涉及状态的checked、selected、disabled一律用prop凡是涉及自定义数据的data-*、title、自定义属性用attr。3.3 什么该放>$(#dataTable).on(click, .btn-del, function () { // 这里的 this 是被点击的那个按钮 });原理是点击按钮 → 事件冒泡到#dataTable→ jQuery 检查事件源是否匹配.btn-del→ 匹配就执行且把this指向匹配元素。因为监听挂在父元素上父元素一直存在后面渲染多少行都能被接住。选择器精度这里有个细节很多人写委托时选择器写得太宽// 反例选择器太宽容易误伤 $(#dataTable).on(click, button, function () { /* 删除逻辑 */ });表格里以后要是加了个查看详情按钮也会命中这条规则然后被当成删除执行。选择器必须写到能唯一标识行为用 class 而不是标签名$(#dataTable).on(click, .btn-del, function () { ... }); $(#dataTable).on(click, .btn-edit, function () { ... });另一个常见问题是委托写在document上// 不推荐除非确实需要 $(document).on(click, .btn-del, function () { ... });能用但缺点明显页面上任何一次点击都要冒泡到 document 才判断事件链最长而且如果页面上有多张表格选择器可能误伤别的表。委托的落点原则是离目标最近的、且在绑定时就已存在的父元素通常就是#dataTable或者tbody。4.3 委托里拿不到正确 this 的两种情况第一种是用了箭头函数。jQuery 委托依赖this的动态绑定箭头函数会把this锁死在定义时的作用域拿到的是 window 或者外层对象。写 ES5 的function就对了。第二种是在委托回调里又套了一层each或者setTimeout里面再用this就变了$(#dataTable).on(click, .btn-del, function () { var $btn $(this); // 先缓存 setTimeout(function () { $btn.closest(tr).remove(); // 这里不能用 this }, 300); });养成委托回调第一行先var $this $(this)的习惯能省掉大量莫名其妙的 bug。提示委托还有个附赠好处。用.on()委托绑定的事件元素被 remove 之后不会造成内存泄漏而直接绑在元素上的事件如果元素被移除但没解绑在老版本 IE 上会有泄漏风险。这也是为什么表格这类高频增删的场景我强烈建议全用委托。5. 排序、筛选、分页前端三件套的最小实现5.1 排序别在 DOM 上动刀用 jQuery 直接操作 DOM 排序是可行的.detach()收集再按序 append但代码又长又容易出错尤其是带合并单元格或者隔行变色的时候。数据优先模型的排序只有三步function sortTable(key, desc) { tableData.sort(function (a, b) { var va a[key], vb b[key]; // 数字按数值排字符串按本地化规则排 if (typeof va number typeof vb number) { return desc ? vb - va : va - vb; } return desc ? String(vb).localeCompare(String(va), zh-CN) : String(va).localeCompare(String(vb), zh-CN); }); renderTable(tableData); }两个细节值得说。一是localeCompare的第二个参数中文排序不加zh-CN会按 Unicode 码点排结果跟人的直觉完全不符阿会跑到张后面。二是数字和字符串要分开处理10 - 9的结果是 1因为减法会隐式转数字但10 9是 true字符串比较逐字符比。见过用比较数字字符串写排序的结果 10 排在 9 前面找半天。带箭头指示的表头切换也很简单用一个状态变量记当前排序列和方向var sortState { key: id, desc: false }; $(#dataTable).on(click, th.sortable, function () { var key $(this).attr(data-field); sortState.desc (sortState.key key) ? !sortState.desc : false; sortState.key key; sortTable(key, sortState.desc); // 更新箭头 $(th.sortable).removeClass(asc desc); $(this).addClass(sortState.desc ? desc : asc); });5.2 筛选过滤数组不是隐藏行$(tr).hide()这种筛选在行数少的时候能跑但会有一个致命问题筛选状态下做分页或者做全选你会把这些隐藏行的状态也带进去。正确做法还是过滤数组用一个viewData表示当前视图数据var allData []; // 全量 var viewData []; // 当前视图筛选排序后 function applyFilter(keyword) { keyword $.trim(keyword).toLowerCase(); viewData !keyword ? allData.slice() : allData.filter(function (item) { return String(item.name).toLowerCase().indexOf(keyword) -1 || String(item.id).indexOf(keyword) -1; }); currentPage 1; // 筛选后必须回到第一页 renderPage(); }currentPage 1这行不能漏。用户在第五页输入筛选词结果筛出来只有 3 条数据一共 1 页你还停在第 5 页表格就是一片空白用户以为筛选坏了。5.3 分页切片渲染不要把全量塞进 DOMvar pageSize 10; var currentPage 1; function renderPage() { var start (currentPage - 1) * pageSize; var pageList viewData.slice(start, start pageSize); renderTable(pageList); renderPager(viewData.length, currentPage, pageSize); } function renderPager(total, page, size) { var totalPage Math.ceil(total / size) || 1; var html ; html button classpg-prev (page 1 ? disabled : ) 上一页/button; html span page / totalPage 共 total 条/span; html button classpg-next (page totalPage ? disabled : ) 下一页/button; $(#pager).html(html); }分页这套逻辑里最容易错的是边界值总数 0 时totalPage算出来是 0页码显示 1 / 0 就很怪所以加|| 1。还有删除最后一页最后一条数据之后currentPage超过了totalPage页面上什么都没有得补一句校正var totalPage Math.ceil(viewData.length / pageSize) || 1; if (currentPage totalPage) currentPage totalPage;6. 千行表格不卡的关键渲染性能三板斧6.1 第一板斧批量操作减少 DOM 调用次数浏览器渲染的成本主要在重排reflow和重绘repaint。每一次append、css修改、text修改只要影响了布局就可能触发一次重排。循环里做 1000 次就是 1000 次重排不掉帧才怪。对比一下实测数据Chrome1000 行 × 5 列渲染方式耗时约说明循环append($tr)800~1200ms每行一次 DOM 插入重排累积循环append(htmlString)300~500ms每次仍是独立插入字符串解析有开销拼串 一次html()40~80ms一次解析一次插入重排只有一轮DocumentFragment30~60ms与拼串接近但内存占用略低结论很明确批量场景一律走拼串 一次 html()。注意html()是整体替换如果表格里已经有内容且你只想追加用append(htmlString)同样是单次插入效果差不多。用 DocumentFragment 的写法也贴一下适合需要 jQuery 对象操作比如批量绑属性的场景var frag document.createDocumentFragment(); for (var i 0; i list.length; i) { var tr document.createElement(tr); tr.setAttribute(data-id, list[i].id); tr.innerHTML td list[i].id /tdtd escapeHtml(list[i].name) /td; frag.appendChild(tr); } $(#dataTable tbody).empty().append(frag);6.2 第二板斧避开布局抖动有个隐蔽的性能杀手叫读写交替。这段代码看着没问题实际上每次循环都在强制浏览器同步计算布局// 慢读写交替 for (var i 0; i rows.length; i) { var h $(rows[i]).height(); // 读触发布局计算 $(rows[i]).css(line-height, h px); // 写让布局失效 }正确的做法是先读后写把所有的读集中在一起写集中在一起var heights []; for (var i 0; i rows.length; i) { heights.push($(rows[i]).height()); } for (var j 0; j rows.length; j) { $(rows[j]).css(line-height, heights[j] px); }这条原则在表格里最常见的场景就是让所有行的行高与内容最高的那一行对齐务必先收集高度再统一设置。6.3 第三板斧超过一定行数该考虑虚拟滚动了拼串 一次插入能把 1000 行压到 80ms 左右但 5000 行的时候就是 400ms 起步而且 DOM 节点太多滚动起来也发顿。这时候有两条路。一条是上插件用别人的成熟方案省事一条是自己写虚拟滚动原理不复杂外层容器固定高度overflow: auto内层放一个占位元素高度 总行数 × 单行高度滚动时算出当前可视区域对应哪几行只渲染这几行加前后各 10 行的缓冲用transform: translateY()或者padding-top把渲染出的行推到正确位置。var rowHeight 36; var buffer 10; $(#scrollBox).on(scroll, function () { var scrollTop this.scrollTop; var start Math.max(0, Math.floor(scrollTop / rowHeight) - buffer); var end start Math.ceil(this.clientHeight / rowHeight) buffer * 2; var slice viewData.slice(start, end); renderRows(slice, start); // 内部用 translateY 定位 });滚动事件记得节流不然每一像素的滚动都触发一次渲染var timer null; $(#scrollBox).on(scroll, function () { clearTimeout(timer); var self this; timer setTimeout(function () { doRender(self); }, 16); });提示行数超过 2000 且需要排序、筛选、编辑的表格我的建议是别再自己造轮子了。自己写的虚拟滚动在遇到行高不一致比如单元格内容换行时会变得非常难受因为高度是动态的位置推算全得重来。这种场景直接选一个成熟表格组件把精力留给业务逻辑更划算。7. 那些反复踩的坑一份速查表7.1 常见问题的现象、成因与解法现象大概率成因排查动作解决动态加入的按钮点击无反应事件绑定时元素不存在检查绑定代码位置改用事件委托删除后删错了行用了parent().parent()或索引错位打印被删行的>// 稳 var name $tr.find(td[data-fieldname]).text(); // 不稳合并单元格后必错 var name $tr.find(td).eq(1).text();三是:checked选择器在大量元素上很慢。表格有 2000 行每行一个复选框你写$(input:checked)jQuery 会遍历所有 input 逐个判断。改写成$(input[typecheckbox]).filter(:checked)或者干脆自己维护一个选中 id 的 Set性能差距在千行级别上很明显。var selectedIds {}; // 用对象做 Set兼容性好 $(#dataTable).on(change, .row-checkbox, function () { var id $(this).closest(tr).attr(data-id); if (this.checked) { selectedIds[id] true; } else { delete selectedIds[id]; } updateSelectedCount(); });这种自己维护选中集合的做法还有个额外好处分页切换、重新渲染之后选中状态依然在不会因为 DOM 重建而丢失。这一点在批量操作的后台页面里是刚需用户翻了三页勾了一堆东西结果一翻页全没了体验会非常差。8. 一些实操中总结出来的小技巧最后这几段不讲体系纯讲我这些年攒下来的一些顺手的小招。用事件命名空间管理多套监听。表格上的事件一多容易互相干扰。给事件加命名空间解绑的时候可以精确打击$(#dataTable).on(click.tblSort, th.sortable, fn1); $(#dataTable).on(click.tblDel, .btn-del, fn2); // 只解绑排序相关的 $(#dataTable).off(click.tblSort);框架切换时记得清空。$(#dataTable tbody).empty()比.html()略快一点点而且语义更清楚。但要注意empty()会一并清掉绑在子元素上的数据和事件如果你在行上存了.data()需要先清理再 empty否则有内存泄漏隐患。用事件委托的话这个问题基本不存在这也是我一直推荐委托的原因之一。加一个无数据占位行但别让它参与计算。表格数据为空时显示一行暂无数据视觉上必要。但一定要给它加一个特殊 class比如row-empty并且在所有涉及行遍历的函数里排除掉它——行数统计、表格转 JSON、全选逻辑全都要排除。我见过全选把暂无数据这行也勾上的非常尴尬。样式尽量用 CSS别用 jQuery 去改。$tr.css(background, #f5f5f5)这种写法在动态渲染之后就会丢失因为新渲染的行没有这个内联样式。悬停高亮、斑马纹、选中态这些全部写成 CSS 类渲染时根据数据打上对应的 class稳定可靠。#dataTable tbody tr:hover { background: #f5f7fa; } #dataTable tbody tr.is-selected { background: #e8f0fe; }接口返回的数据先洗一遍再进数组。后端给的字段类型经常不统一id 有时候是数字有时候是字符串排序和比对的时候就会出问题。统一做一次转换所有 id 转字符串所有数量字段转数字时间字段统一格式。这一步花不了几分钟能省掉后面无数个为什么这条匹配不上的排查。我个人在实际项目里的体会是jQuery 操作表格本身没什么难的难的是先把数据模型定死然后所有操作都收敛到这一条链路上。只要坚持改数据 → 重渲染这个单向流代码写到几千行也乱不了一旦允许这里顺手改一下 DOM三个月后你自己都不敢动那张表。至于性能绝大多数后台页面在分页 拼串渲染的组合下就完全够用了真到了需要虚拟滚动的量级那说明业务已经长到该换技术方案的时候了。
