原生 <tr> 标签无法可靠支持拖拽排序，因其对 DnD API 支持残缺；必须将 <tbody> 作为拖拽容器，通过 draggable="true" 触发事件、dataTransfer 传索引、dragover.preventDefault() 启用 drop，并基于 clientY 计算插入位置。
tr 拖拽排序的核心限制在哪
原生 <tr> 标签本身不支持 draggable 属性的完整拖拽流程——即使设了 draggable="true"，dragstart 事件里无法可靠获取 dataTransfer 的行数据（尤其跨浏览器时），且 dragover 在 <tbody> 上默认被阻止，drop 也常不触发。这不是写法问题，是规范限制：表格元素对 DnD 的支持残缺，不能像 <div> 那样直接用原生 API 完整实现排序。
用 dragstart + dragover + drop 的最小可行方案
必须绕过 <tr> 直接操作，改用 <tbody> 作为拖拽容器，并手动管理插入位置。关键不是“让 tr 可拖”，而是“让 tbody 接收拖放并重排 tr”：
-
draggable="true"加在<tr>上仅用于视觉反馈和触发事件，实际数据靠dataTransfer.setData("text/plain", index)传序号（不要传 HTML 或 DOM） -
<tbody>必须监听dragover并调用event.preventDefault()，否则drop不会触发 -
drop事件中，用event.clientY对比所有<tr>的getBoundingClientRect().top，找到最接近的插入点（不是靠event.target，它可能是 td 或 tr） - 插入逻辑用
insertBefore(newTr, refTr)或before()，避免用innerHTML重写，否则绑定的事件或状态会丢失
示例片段（简化版）：
tbody.addEventListener('dragover', e => e.preventDefault());
tbody.addEventListener('drop', e => {
const fromIndex = +e.dataTransfer.getData('text/plain');
const rect = e.currentTarget.getBoundingClientRect();
const y = e.clientY - rect.top;
const rows = Array.from(tbody.querySelectorAll('tr'));
const targetIndex = rows.findIndex((tr, i) => {
const r = tr.getBoundingClientRect();
return y < r.top + r.height / 2 && i !== fromIndex;
});
if (targetIndex === -1) return;
const trs = tbody.querySelectorAll('tr');
const moved = trs[fromIndex];
if (fromIndex < targetIndex) {
tbody.insertBefore(moved, trs[targetIndex + 1]);
} else {
tbody.insertBefore(moved, trs[targetIndex]);
}
});为什么推荐用第三方库（如 sortablejs）而不是手写
手写容易漏掉边界情况，比如：
立即学习“前端免费学习笔记（深入）”；
- 拖拽过程中快速移动导致
drop位置判断漂移（尤其滚动 tbody 时） - Firefox 对
dataTransfer的setData类型更严格，"text/plain"是唯一稳定选项 - 移动端没有原生 drag 事件，需额外加 touch 适配，成本陡增
- 键盘可访问性（如用空格/回车触发拖拽）几乎不可能靠手写覆盖
sortablejs 内部用的是虚拟占位符 + 坐标插值，兼容 IE10+，且支持 handle 选项只允许特定列拖拽（比如只让操作按钮触发，而非整行），比自己维护 dragstart 状态干净得多。
如果必须用纯原生，注意 tbody 的 overflow 和 scroll 行为
当 <tbody> 设了 max-height + overflow-y: auto，拖拽时滚动条会干扰 getBoundingClientRect() 计算 —— 因为该方法返回的是相对于视口坐标，而 tbody 滚动后，tr 的实际文档位置没变，但视口坐标变了：
- 正确做法：用
tr.offsetTop + tbody.scrollTop替代getBoundingClientRect().top来计算相对 tbody 顶部的距离 - 或者监听
scroll事件，在拖拽中暂停判断，等 scroll 结束再更新位置缓存 - 更稳妥的替代：把整个 table 包进一个固定高度容器，tbody 不设 overflow，由外层容器滚动 —— 这样
getBoundingClientRect()就不会因内部滚动错乱
拖拽排序真正难的从来不是“怎么让 tr 动起来”，而是“怎么让它在各种滚动、缩放、嵌套布局下，每次都插到人眼认为‘该在的位置’”。这点上，浏览器原生能力始终留了一道缝，得靠策略补。
