JavaScript表格排序实战：比较器设计、稳定排序与DOM复用

1. 表格排序看似简单，坑都在“点一下箭头”之后

前端圈有句话：表格排序是每个前端都写过、但很少有人写对的功能。接到“给表格加个排序”的需求时，多数人的第一反应是——给表头绑个点击事件，拿数组sort()一下，再把 DOM 重新拼一遍，二十分钟收工。我第一次也是这么干的，结果上线第二天就收到反馈：数字列排出来是“1, 10, 100, 2”这种顺序，日期列完全乱套，还有用户点了几次箭头后发现数据莫名其妙少了两行。

问题的根源在于，原生Array.prototype.sort()默认把所有元素转成字符串再按 UTF-16 码元比较。这个行为对["apple", "banana"]没问题，对[1, 10, 100, 2]就是灾难。而表格里的数据千奇百怪：金额带千分位逗号、百分比带百分号、日期是“2024-03-05”这种字符串、状态列是“已完成/进行中/未开始”这种业务枚举，甚至还有“3.5万”这种中英文混排的数量表达。排序功能的本质不是调一个 API，而是为每一列定义一套“什么叫做大、什么叫做小”的比较规则。

这篇内容面向的是已经会写基础 DOM 操作、但被表格排序折磨过的前端开发者，也适合需要给后台管理系统补一个通用排序能力的中高级同学。我会从比较器的设计讲起，把数据类型识别的坑、中文与多语言排序、稳定排序的意义、DOM 复用与性能、以及和分页/筛选/编辑态的联动冲突，一条条拆开讲。所有代码都是原生 JavaScript 加 CSS，不依赖任何框架，你在 Vue、React 或者纯模板渲染的项目里都能直接搬过去用。

先给个整体思路，避免后面看得云里雾里：排序功能可以拆成四层——取值层（从单元格里拿到真正用于比较的数据）、比较层（针对列类型定义比较器）、状态层（记录当前排序列和方向，支持三态循环）、渲染层（把排好序的数据映射回 DOM，并处理箭头图标和可访问性）。大多数出问题的实现，都是把这四层揉成了一坨，导致加一个新类型就得改动全身。

提示：如果你的表格数据来自后端接口，先确认一件事——排序到底在前端做还是后端做。数据量超过一两千行、或者有分页的情况下，前端排序只能排当前页，用户看到的结果是错的，这个坑后面会专门讲。

2. 取值层：单元格里显示的文本，八成不是你要比较的值

2.1 为什么不能直接读 innerText

最直觉的做法是遍历tbody的每一行，用row.cells[i].innerText拿到文本，然后排序。这个方案在纯静态展示表格里能跑，但一旦表格带上了格式化，就全线崩溃。举几个我实际遇到过的例子：金额列渲染成¥12,800.00，parseFloat得到NaN；库存列显示1,024 件，去掉逗号还得再去掉单位；进度列是<div class="bar" style="width:72%">，innerText 是空的；操作列里全是按钮，根本没有可比较的内容。

更隐蔽的问题是渲染精度。假设金额后端返回12800.456，UI 上为了好看只显示两位小数12,800.46，如果按 innerText 排序，12800.451和12800.456会被判定为相等，排序结果就和用户的直觉不符。正确的做法是让数据源和展示层分离：每一行在渲染时，把原始值挂到 DOM 上。

// 渲染时把原始排序值写进 data 属性 function renderRow(item) { const tr = document.createElement('tr'); tr.dataset.id = item.id; tr.innerHTML = ` <td>function parseCellValue(text, type) { const raw = (text || '').trim(); if (raw === '' || raw === '-' || raw === '--') { return { empty: true, value: null }; } switch (type) { case 'number': { // 去掉货币符号、千分位、空白，保留数字、小数点和负号 const cleaned = raw.replace(/[¥$€£,\s]/g, ''); // 处理“3.5万”“1.2亿”这类中文数量单位 const unitMatch = cleaned.match(/^(-?\d+(?:\.\d+)?)(万|亿|千)?$/); if (unitMatch) { const base = parseFloat(unitMatch[1]); const unitMap = { 千: 1e3, 万: 1e4, 亿: 1e8 }; const multiplier = unitMap[unitMatch[2]] || 1; return { empty: false, value: base * multiplier }; } const num = Number(cleaned.replace(/%$/, '')); return { empty: false, value: Number.isNaN(num) ? null : num }; } case 'date': { const ts = Date.parse(raw.replace(/[年月]/g, '-').replace(/日/g, '')); return { empty: false, value: Number.isNaN(ts) ? null : ts }; } case 'string': default: return { empty: false, value: raw }; } }

这段代码里有几个决定成败的细节。第一，空值的处理要统一。表格里空单元格通常是-或者空白，如果直接参与比较会得到NaN，而NaN参与任何比较都返回false，导致sort的行为完全不可预测。我的约定是空值统一标记为empty: true，排序时无论升序降序都排在最后——这是大多数后台系统的用户预期，也和主流表格组件的默认行为一致。

第二，中文数量单位必须单独处理。parseFloat('3.5万')返回3.5，这就是典型的“看着对其实错”的坑，因为一万个用户里可能只有一个人会去核对那个数字。正则里把单位单独捕获、乘以对应倍数，才算真正对上业务语义。

第三，Number()比parseFloat()更适合做最终校验。parseFloat('12abc')返回12，会悄悄吞掉脏数据；Number('12abc')返回NaN，能让你及时发现文本格式不符合预期，把这类值归为null而不是给一个错误的数字。

2.3 日期解析的时区陷阱

日期是排序里最容易出问题的一类。假设后端返回2024-03-05，你的格式化函数把它渲染成2024/03/05，然后用Date.parse解析。看似没问题，但Date.parse('2024-03-05')在规范里被当作UTC 时间，而Date.parse('2024/03/05')被当作本地时间，两者在东八区相差整整 8 小时。如果你混用了这两种格式，跨零点的数据排出来就会错位。

我的做法是永远用时间戳比较，并且解析时统一格式。最稳妥的写法是手工拆分：

function toTimestamp(str) { const m = str.match(/(\d{4})[-/年](\d{1,2})[-/月](\d{1,2})/); if (!m) return null; return new Date(+m[1], +m[2] - 1, +m[3]).getTime(); }

new Date(year, monthIndex, day)这个构造函数用的是本地时区，且不会有字符串解析的各种怪异行为。虽然它在处理“纯日期”时比Date.parse啰嗦，但 predictability 高得多。如果你的表格里有精确到时分秒的数据，就把时分秒也一起拆进去，别偷懒用字符串解析。

注意：如果你的表格需要跨时区展示，比如总部和海外分部看同一份数据，那就不能依赖本地时区，必须统一存 UTC 时间戳、统一用 UTC 比较，只在渲染时转成本地时区显示。这个决定要在一开始就和产品确认，后期改起来成本极高。

3. 比较层：把“谁大谁小”这件事显式地写出来

3.1 一个合格的比较器长什么样

有了取值层，比较层就清爽了：输入的永远是归一化之后的值（数字、时间戳、字符串），输出永远是-1 / 0 / 1。我习惯为每一列配置一个描述对象，而不是写一堆if-else：

const columnConfig = { amount: { type: 'number', compare: compareNumber }, createdAt: { type: 'date', compare: compareNumber }, name: { type: 'string', compare: compareChinese }, status: { type: 'rank', compare: compareNumber }, }; function compareNumber(a, b) { if (a.empty && b.empty) return 0; if (a.empty) return 1; // 空值永远沉底（升序时排最后） if (b.empty) return -1; return a.value - b.value; } function compareChinese(a, b) { if (a.empty && b.empty) return 0; if (a.empty) return 1; if (b.empty) return -1; return a.value.localeCompare(b.value, 'zh-Hans-CN', { numeric: true }); }

为什么用a.value - b.value而不是写三个分支？因为Array.sort的比较函数只要求返回正负零三种结果，差值天然满足这个契约，代码最短且不会出错。但要注意浮点数相减的精度问题——如果要比较的是两个非常接近的小数，差值可能小到被判定为 0，不过在实际业务里金额和时间戳的精度远没到这个级别，我一般不额外处理。

空值永远沉底这条规则必须显式编码，这是我认为表格排序里最重要的隐性约定之一。很多实现里空值会跟着升序跑到最前面，用户一升序就看到一片空白行，体验极差。而且升序降序都要沉底，不能靠“降序时自然跑到后面”蒙混过关，得靠return 1和return -1的对称逻辑保证。

3.2 中文排序：为什么 localeCompare 比你想的重要

字符串列用localeCompare看起来是常识，但很多人不知道要传 locale 参数，或者传错了格式。默认调用localeCompare(b)会使用运行环境的默认语言，在英文系统上“张”和“李”的排序结果就是按 Unicode 码点排的，对中文用户毫无意义。带上'zh-Hans-CN'之后，比较会按拼音顺序走，“阿”在前“邹”在后，符合中文用户直觉。

{ numeric: true }这个选项值得单独强调。它让"item2"排在"item10"前面，而不是按字符比较让"item10"跑到前面去。表格里的编号列、版本号列、房间号列几乎都需要这个行为。我见过一个会议室预约系统，房间号A-2和A-10排序结果颠倒，排查了半天才发现是这个选项没开。

对于多音字，localeCompare也有局限。比如“重”在“重庆”里读 chóng，在“重要”里读 zhòng，拼音排序会把“重庆”按 zhòng 排。折叠表场景下如果对精度要求高，只能靠后端打拼音字段，或者维护一个多音字词表做预处理。这是业务层面的问题，前端能做的有限，提前和产品对齐预期比硬啃更重要。

3.3 稳定排序的隐性价值

ES2019 之后，Array.prototype.sort被规范要求为稳定排序，意味着值相等的元素保持原有相对顺序。这个特性在表格里非常有价值：用户先按“部门”排序，再按“姓名”排序，期望的是“部门内部按姓名排”，而不是“姓名排完之后部门顺序被打乱”。如果你的项目还要兼容老旧浏览器，就得自己实现稳定排序，或者用“先按次要字段排、再按主要字段排”的方式模拟。

// 先按姓名排（次要），再按部门排（主要），利用稳定性实现多级排序 rows.sort((a, b) => compareChinese(a.name, b.name)); rows.sort((a, b) => compareChinese(a.dept, b.dept));

不过说实话，现在还在用不支持稳定排序的浏览器版本的用户群体已经极小，我的建议是把稳定性当作基础能力来设计，而不是当成兼容性负担。多级排序的交互（按住 Shift 点表头追加排序）在数据看板场景里很常见，稳定排序是实现它的前提。

4. 状态层：三态循环与箭头方向，别小看这个交互细节

4.1 升序、降序、不排序的三态设计

表格排序的交互约定俗成是三态循环：第一次点击升序，第二次降序，第三次取消排序回到原始顺序。只有两态的实现用起来很难受，用户想回到初始状态只能刷新页面。实现上用一个状态对象记着当前列和方向：

const sortState = { column: null, direction: null, // 'asc' | 'desc' | null originalOrder: [], // 保存初始行顺序，用于取消排序时还原 }; function handleHeaderClick(columnKey) { if (sortState.column !== columnKey) { sortState.column = columnKey; sortState.direction = 'asc'; } else if (sortState.direction === 'asc') { sortState.direction = 'desc'; } else if (sortState.direction === 'desc') { sortState.column = null; sortState.direction = null; } else { sortState.direction = 'asc'; } applySort(); }

originalOrder是一个容易被忽略但必须要有的东西。取消排序时不能重新请求接口，也不能假设“DOM 现在的顺序就是初始顺序”（用户可能已经排过好几次了），只能是首次渲染时把行元素或行 ID 的原始顺序记录下来。我用行 ID 数组存，因为 DOM 元素会被重排，存 ID 更稳。

这里还有个细节：一旦数据源发生变化（新增、删除、筛选），原始顺序要重新记录。我的做法是在数据加载完成的回调里统一重置sortState和originalOrder，而不是在每个操作里各自处理。集中管理，避免遗漏。

4.2 箭头图标的 CSS 方案对比

排序箭头有三种常见实现方式，各有取舍。我列个表对比一下，你可以按项目情况选：

我现在统一用内联 SVG，因为它的可控性最好，而且能给箭头加过渡动画。下面是我常用的结构，用aria-sort属性同时承担“状态存储”和“无障碍语义”两个职责：

<th scope="col">.th-sort .sort-icon path { opacity: .25; transition: opacity .15s; } th[aria-sort="ascending"] .arrow-up, th[aria-sort="descending"] .arrow-down { opacity: 1; } th[aria-sort="ascending"] .arrow-down, th[aria-sort="descending"] .arrow-up { opacity: .15; }

这里有必要解释为什么表头里面要套一个<button>。直接给<th>绑 click 在视觉上没问题，但键盘用户没法聚焦、没法触发，屏幕阅读器也读不出“这是可操作的”。套一个透明背景的按钮，既保留了视觉一致，又拿到了原生键盘支持和焦点样式。再配上aria-sort，读屏软件会播报“金额列，升序排列”，无障碍这块就算做到位了。很多人觉得内部系统不用管无障碍，但实际经验是——加这两行属性和一个 button 的成本几乎为零，收益是长期的，顺手做掉比以后补划算。

提示：aria-sort只应该出现在当前排序的那一列上，其他列用aria-sort="none"。有些实现给所有列都写ascending，读屏时会让人完全混乱。

4.3 视觉提示与加载态

排序是瞬间完成的，但如果你的排序涉及大量 DOM 操作，或者触发了后端请求，就必须给反馈。前端排序超过 200 行的情况下批量操作 DOM 会有明显卡顿，我的做法是在点击后给表头加一个is-sorting类，配合一条细进度条或箭头旋转动画，等requestAnimationFrame之后再做重排。用户感知到的响应速度会好很多，这点心理学层面的东西，做过交互的同学应该都有体会。

5. 渲染层：重排 DOM 的三种做法，性能差十倍

5.1 为什么不能每次都重新拼 innerHTML

最简单的渲染方式是tbody.innerHTML = rows.map(toHTML).join('')。这个方式在几百行的表格里勉强能用，但它有两个致命问题：其一，所有行元素被销毁重建，之前绑定的行内事件全部失效，行内的输入框、下拉框、展开状态全部重置；其二，浏览器要重新完成整个子树的样式计算、布局和绘制，数据量一大就卡。

我在一个六七百行的对账表格上踩过这个坑：每次点表头，页面要卡将近半秒，滚动位置还会跳。用户投诉不断。后来改成基于 DOM 节点搬移的方案，卡顿直接消失，因为浏览器对“移动已存在的节点”的优化远好于“销毁再创建”。

5.2 用 DocumentFragment 批量搬移

核心思想是：排序时只调整行的顺序，不重建行。做法是把排好序的行元素逐个appendChild到一个DocumentFragment里，最后一次性挂回tbody。DocumentFragment是离屏的，appendChild到它上面不会触发重排，而appendChild一个已存在的节点会自动把它从原位置摘下，这正好是我们需要的“移动”语义。

function applySort() { const tbody = document.querySelector('#dataTable tbody'); const rows = Array.from(tbody.rows); // 按行 ID 还原或排序 let orderedRows; if (!sortState.column) { const idIndex = new Map(rows.map(r => [r.dataset.id, r])); orderedRows = sortState.originalOrder .map(id => idIndex.get(id)) .filter(Boolean); } else { const cfg = columnConfig[sortState.column]; const decorated = rows.map(row => { const cell = row.querySelector(`[data-col="${sortState.column}"]`); const raw = cell?.dataset.sortValue ?? cell?.textContent; const parsed = parseCellValue(raw, cfg.type); return { row, key: parsed }; }); decorated.sort((a, b) => { const res = cfg.compare(a.key, b.key); return sortState.direction === 'desc' ? -res : res; }); orderedRows = decorated.map(d => d.row); } // 一次性搬移，触发一次重排 const fragment = document.createDocumentFragment(); orderedRows.forEach(row => fragment.appendChild(row)); tbody.appendChild(fragment); }

这段代码有几个点值得逐条拆开说。

排序时先把键解析出来存成数组，而不是在比较函数里反复调用parseCellValue。比较函数在一次sort中会被调用 O(n log n) 次，如果每次都在里面解析 DOM 文本、跑正则，开销会翻好几倍。先把键算好、和行元素绑成对象，比较时只做数值运算，这是标准的“装饰-排序-取消装饰”模式（Schwartzian transform），在数据量大的时候收益非常明显。

降序不重写比较器，而是把结果取反。这样每个列只需要维护一个升序比较器，降序由外层统一处理。但要注意空值沉底的逻辑——如果比较器返回 1 表示空值在后，取反之后空值就跑到前面去了。所以正确做法是：空值判断放在比较器里，并且在降序时不取反空值的结果。我上面的写法其实有这个隐患，更严谨的写法是在比较器里完成方向处理，或者在装饰阶段把空值单独分出来：

decorated.sort((a, b) => { // 空值始终沉底，不受方向影响 if (a.key.empty !== b.key.empty) return a.key.empty ? 1 : -1; const res = cfg.compare(a.key, b.key); return sortState.direction === 'desc' ? -res : res; });

这个细节我强烈建议你在实现时验证一遍：造一条空值数据，分别升序和降序，确认它始终在最底下。

tbody.appendChild(fragment)只触发一次布局。如果改成循环里直接tbody.appendChild(row)，每次都会触发一次重排，性能会退化到接近重建方案。DocumentFragment的价值就在这里，它把 n 次重排压缩成 1 次。

5.3 排序与筛选、分页的联动冲突

这是实际项目里最容易出事故的地方，我把它单独拎出来讲。表格通常同时具备排序、筛选、分页、搜索四个能力，它们共享同一份数据状态，一旦处理不当就会互相打架。

冲突一：排序排的是当前页还是全量。有分页的表格，前端排序只能对当前页的 DOM 行排序，用户点了“金额升序”，看到的是第 1 页内部的升序，翻到第 2 页又是另一批数据，业务语义完全错了。这种情况下排序必须交给后端，前端只负责把sortField和sortOrder传给接口，同时排序动作必须把页码重置到第一页——否则用户在第 5 页点了升序，重新请求后数据显示的还是第 5 页，看起来像是没反应。这个重置逻辑写在一处统一处理，别散落。

冲突二：筛选后取消排序，行丢了一半。如果originalOrder里存的是全量行 ID，用户在筛选状态下取消排序，用原始顺序还原时会把被筛掉的行也塞回去。正确做法是每次筛选之后重新记录一次当前可见行的顺序，或者干脆把“数据状态”和“排序状态”分开：数据层永远保持一份当前筛选后的数组，排序只是对这个数组做一份拷贝再重排，渲染永远从数据数组出发。这个思路比直接操作 DOM 更稳，也是我更推荐的做法。

冲突三：单元格处于编辑态时重排，草稿丢失。行内有输入框且用户正在输入一半，此时点了表头排序，appendChild移动节点其实不会丢失输入内容（这是 DOM 搬移相对重建的优势），但如果你的重排逻辑走了重新渲染的路径，内容就没了。这也是我坚持用节点搬移方案的原因之一。另外可以加一个保护：检测到有输入框处于:focus状态时，提示用户“排序将丢弃未保存的修改”，或者干脆禁用排序直到焦点离开。

6. 把这些坑逐个排掉：一次完整的排查链路

6.1 症状一：数字列排成 1、10、100、2

先定位是哪一层出的问题。打开控制台，选中一个数字单元格，执行cell.dataset.sortValue和cell.textContent，看取到的值是什么。

• 如果dataset.sortValue是"12800"这种带引号的数字字符串，说明取值层没问题，问题在比较层没把它转成 number。检查columnConfig里这一列的type是不是写成了string，或者compare用的是字符串比较器。
• 如果dataset.sortValue是undefined，说明渲染时没写这个属性，取值层走了textContent兜底，而textContent是"¥12,800.00"，Number()返回NaN，导致所有行比较结果都是 0，顺序保持原样。
• 如果取到的是"12,800"且类型判定为 number，检查parseCellValue里的正则有没有覆盖这个币种符号。

我在一个项目里遇到的是第三种变体：金额符号是全角的￥（U+FFE5），而正则里写的是半角¥（U+00A5），看起来一模一样但匹配不上。这种字符层面的坑，只能靠把原始值console.log出来逐个字符核对，光看页面上渲染的结果是看不出来的。

6.2 症状二：排序后表头和表体错位

这个症状的典型表现是：表头显示“金额升序”，但数据看着是乱的，或者表头箭头指向和数据顺序不符。排查顺序是这样的——

第一，检查排序方向和箭头显示是否来自同一个状态源。如果箭头是根据classList判断、排序是根据另一个变量判断，二者很容易不同步。统一读sortState.direction，箭头和aria-sort都从这里派生。

第二，检查是不是有多个表头同时存在。有些表格做了固定表头（sticky header），DOM 里有两份th，点击事件绑在了非固定的那份上，固定的那份没有更新。这类问题看代码看不出来，得在控制台里document.querySelectorAll('th[data-column="amount"]').length数一下，大于 1 就是它。

第三，检查tbody里有没有非数据行。表格里经常混入“展开详情行”“加载更多行”“空状态行”，如果排序逻辑用tbody.rows全量遍历，这些行会被当成数据行参与排序，结果就乱了。我的做法是给数据行统一加>function sortTable(tableEl, { column, direction, columnConfig, emptyLast = true }) { const tbody = tableEl.tBodies[0]; const rows = Array.from(tbody.querySelectorAll('tr[data-row]')); const cfg = columnConfig[column]; if (!cfg) return; const parsed = rows.map(row => { const cell = row.querySelector(`[data-col="${column}"]`); const raw = cell?.dataset.sortValue ?? cell?.textContent ?? ''; return { row, key: parseCellValue(raw, cfg.type) }; }); parsed.sort((a, b) => { if (emptyLast && a.key.empty !== b.key.empty) { return a.key.empty ? 1 : -1; } const res = cfg.compare(a.key, b.key); return direction === 'desc' ? -res : res; }); const frag = document.createDocumentFragment(); parsed.forEach(p => frag.appendChild(p.row)); tbody.appendChild(frag); }

接口只暴露“哪张表、哪一列、什么方向”，取值和比较的细节全部由columnConfig承载。新增一种列类型，只需要在配置里加一条，不用动排序主逻辑。这个边界划分很关键——我见过把业务字段判断硬编码进排序函数的代码，后续每加一列都要改核心函数，bug 率直线上升。

7.2 一份可以直接抄的列配置

下面这份配置对应一个典型的订单表格，涵盖了金额、日期、文本、枚举、布尔五种类型，你可以按需裁剪：

const orderColumns = { orderNo: { type: 'string', compare: compareChinese }, customer: { type: 'string', compare: compareChinese }, amount: { type: 'number', compare: compareNumber }, createdAt: { type: 'date', compare: compareNumber }, status: { type: 'rank', compare: compareNumber }, urgent: { type: 'rank', compare: compareNumber }, }; // 渲染时把枚举转成排序权重 const STATUS_RANK = { 未开始: 0, 进行中: 1, 已完成: 2, 已取消: 3 }; const BOOL_RANK = { false: 0, true: 1 };

枚举列的排序权重是一个高频需求，但很少有人提前设计。用户点“状态”列，期望的顺序绝不是按拼音排（“已完成”和“未开始”按拼音排会很怪），而是按业务流程排。所以在渲染阶段就把statusRank写进>test('金额带千分位能正确解析', () => { expect(parseCellValue('¥12,800.00', 'number').value).toBe(12800); }); test('中文数量单位乘倍数', () => { expect(parseCellValue('3.5万', 'number').value).toBe(35000); }); test('空值标记为空', () => { expect(parseCellValue('-', 'number').empty).toBe(true); });

把解析和比较做成纯函数，是我从这些坑里得到的最重要的一条经验。只要这两层是纯的，DOM 层怎么改都不会影响正确性，测试也能用最快的方式跑起来。反过来，如果比较逻辑和 DOM 读取搅在一起，你连写测试都无从下手，出了问题只能靠肉眼观察，效率极低。

最后分享一个我自己一直在用的小检查：每次改完排序相关代码，造一组“故意刁难”的测试数据丢进去——一条空值、一条带单位、一条只差两位小数、一条中文名字、一条特殊字符，五种类型各来一条，点一遍升序降序。这五条能跑通，基本上线就不会出排序事故了。