基于快马平台与马威斯构建可拖拽任务看板实战

上周三下午四点，产品在群里丢了一句：明天上午能不能看到一版能拖的任务看板，卡片左右挪一下状态就跟着变的那种。搁两年前，这话我听完第一反应是排期——拖拽排序、跨列移动、状态同步、多人同时打开不打架，光是把手感调到不别扭，一个前端就得进去三五天。这次我没排期，而是打开快马平台，把需求写成一段话让它先把可运行的看板骨架吐出来，再用马威斯把这件事拆成几块可验收的活，两小时拿到一版能拖动、能落库、能多人同时看的原型，第二天上午直接投屏。这套组合真正省时间的点不在“让工具帮我写代码”，而在于把“数据怎么长”和“活怎么被验收”这两件事前置了，写代码反而成了最短的一段。这篇就把这套基于快马平台与马威斯快速构建可拖拽任务协作看板应用的完整过程摊开讲，包括我为什么这么选、数据结构怎么定、拖拽手感的几个关键参数怎么算、落库和并发怎么收口，以及那些只有真上手拖动过才会遇到的坑。适合三类人看：想用生成式平台快速出原型的产品和独立开发者、手写拖拽交互总是抖动的初中级前端、以及需要给团队搭一套轻量任务协作工具的技术负责人。

1. 方案选型：为什么是生成式平台加协作工具的组合

1.1 三种做法摆在一起比，差别到底在哪

做一个任务协作看板，路子其实就那么三条，但每条路的成本结构和后续维护代价完全不同，选错一次后面全是补丁。

第一条是纯手写。从零搭项目、定路由、写状态管理、接拖拽、设计接口、做持久化。好处是完全可控，坏处是这套东西 80% 是重复劳动，真正有别于其他看板的只有 20% 的业务规则。我做过两次，第一次花了四天，第二次稍微熟一点也花了三天，其中至少一半时间在配环境和写增删改查的样板代码。

第二条是直接用现成的项目管理产品。快是真快，半小时就能拉一个团队进去用，但一旦业务方提出“我们的验收流程要挂在卡片上”“状态流转要卡 WIP 上限”“字段要跟内部的物料表对齐”，你就只能在别人的模型里绕。绕不动的时候，迁数据的成本比自研还高。

第三条就是这次用的：让生成式开发平台先产出一版能跑起来的骨架，我在这版骨架上做外科手术式的改造。它的价值不是“不用写代码”，而是把项目脚手架、路由、基础组件、假数据、接口占位这些“本来就要花半天”的部分压缩到十几分钟，让我从第 30 分钟开始就能思考真正难的问题——排序字段怎么设计、拖拽的命中判定怎么做、并发写怎么不覆盖。

至于马威斯，它在这次里扮演的不是开发工具，而是把整件事切开、派出去、收回来验收的那一层。这件事听起来虚，但非常实：一个“能拖的看板”这种模糊需求，如果不先拆成“卡片能拖动”“拖完状态变了”“刷新后位置还在”“两个人同时拖不炸”这四条可验收的活，你会在第一天晚上十点还在调一个其实没人会注意的动画曲线。

1.2 生成式平台的能力边界：哪些活交给它，哪些必须自己上手

我用下来对这类平台的边界判断比较清晰了，简单列个表，比我讲一堆形容词有用。

我把这张表当成一条纪律：平台负责“从 0 到能跑”，我负责“从能跑到能用”。心里没有这条线的人，最常见的失败模式是不断给平台加需求描述，指望它一次性生成最终形态，结果每次生成都推翻上一次，改到最后连自己都不知道哪一版是对的。我的做法是：第一轮生成后立刻把代码拉下来，之后的所有修改都在本地仓库里用版本管理推进，不再回头让平台重生成整页。这条纪律救了我不止一次。

1.3 先定数据契约再谈界面，顺序反了必然返工

我见过太多人一上来就调卡片长什么样、圆角多少、阴影几层，调了两小时发现数据结构撑不住“一个卡片属于多个人”或者“一列最多只能放五张”，然后推倒重来。

所以这次我的顺序是反的：先花二十分钟把数据契约定死，写在纸上，然后再去看界面。契约就三句话：列是有序的、卡片有序且属于某一列、卡片位置用可比较的数值表达而不是数组下标。这三句话决定了后面所有实现，包括拖拽怎么算位置、并发怎么写、重排什么时候触发。

界面反而简单：看板就是若干列横向排列，每列内纵向排列卡片，卡片可拖动。真正复杂的是“拖动之后那个数值怎么变”，而不是“拖动的时候卡片长什么样”。

2. 数据模型与拖拽原理：把“能拖”拆成可计算的步骤

2.1 列与卡片：排序字段为什么不能用数组下标

先看数据结构，我用的是 TypeScript 风格，字段名尽量直白：

type Column = { id: string; title: string; order: number; // 列之间的顺序 wipLimit?: number; // 可选的 WIP 上限 }; type Card = { id: string; columnId: string; title: string; order: number; // 同列内的顺序，关键字段 assignee?: string; tags: string[]; updatedAt: number; version: number; // 乐观并发用 };

为什么order必须是独立的数值，而不是“卡片在数组里的下标”？因为下标是“位置”不是“身份”。你用数组下标存顺序，意味着每挪动一张卡片，后面所有卡片的下标都要重写。一个列里有 50 张卡，你只挪了第一张到第二张，一条操作要写 49 条记录。这在小数据量下看不出问题，一旦两个人同时操作，两个人的写入集合高度重叠，必然互相覆盖。

用独立的数值order，挪一张卡片最多只需要写它自己一条记录——前提是取一个“中间值”。这就是常见的间隔排序：

假设一列的卡片顺序值是 0、1024、2048、3072。要把卡片 A（0）挪到 B（1024）和 C（2048）之间，新值取(1024 + 2048) / 2 = 1536，写一条记录即可。选 1024 而不是 1 作为初始间隔，是为了给中间插入留足够的空间。

这里有个必须算清楚的边界：如果一直往同一个缝隙里插，会发生什么？间隔 1024 时，第一次中插得到 512，然后 256、128、64、32、16、8、4、2、1、0，同一缝隙最多连续插 10 次就会撞值。撞值的表现是排序不稳定，两张卡片顺序随机跳。所以必须加熔断：当相邻两个order的差值小于 2 时，触发该列的全量重排，把所有卡片按当前顺序重新赋值为 1024 的倍数。

const GAP = 1024; const MIN_GAP = 2; function calcOrder(prev?: number, next?: number): { order: number; needRebalance: boolean } { if (prev === undefined && next === undefined) return { order: GAP, needRebalance: false }; if (prev === undefined) return { order: Math.floor(next! / 2), needRebalance: next! < MIN_GAP }; if (next === undefined) return { order: prev + GAP, needRebalance: false }; const mid = Math.floor((prev + next) / 2); return { order: mid, needRebalance: next - prev < MIN_GAP }; } function rebalance(cards: Card[]): Card[] { return cards .slice() .sort((a, b) => a.order - b.order) .map((c, i) => ({ ...c, order: (i + 1) * GAP })); }

提示：全量重排要在一个事务里提交，或者至少保证重排期间该列被锁定。我踩过一次坑——重排写到一半用户又拖了一下，结果新插入的卡片用的是重排前的旧order，落到了一个完全错误的位置。后面加了“该列重排中禁止拖拽”的短暂锁才解决。

2.2 拖拽的三段式状态机：按下、移动、提交要分开

很多人写拖拽的失败点在于把它当成一个连续事件处理，实际上它必须是三个独立阶段，每个阶段职责不同，混在一起写必然出 bug。

第一阶段是意图判定。指针按下去的那一刻，不能立刻认为用户在拖拽。用户可能只是想点开卡片看详情。我的判定阈值是位移超过 5 像素才算拖拽开始，低于这个值松手就当成一次普通点击。这个 5 像素不是随便定的，它要大于触屏设备的手指抖动幅度（通常在 2 到 3 像素），又要小于用户“明确要拖”的位移（通常在 8 像素以上）。定 1 像素会出现“点一下就飞了”，定 15 像素会出现“我明明拖了它不动”。

第二阶段是跟随与命中检测。拖拽中的卡片用transform: translate3d(x, y, 0)跟着指针走，不要用left/top。原因是transform走合成层，不触发布局重排，60 帧下不掉帧；left/top每帧都在改布局，卡片一多就开始糊。同时原位置要留一个占位符（半透明占位块），告诉用户“松手会落在这里”。这个占位符是拖拽手感的核心，没有它用户全程处于不确定状态。

第三阶段是提交。松手时才算最终的落点，一次性计算新的columnId和order，然后发请求。整个过程里，前端本地状态先改（乐观更新），请求失败再回滚。

三段式的好处是可测。每一段都能单独写测试：位移 3 像素不触发、位移 20 像素触发、松手计算出的order是否符合预期。这几条测试写下来，后面的返工量少一大半。

2.3 命中检测用卡片中心线，不用指针坐标

命中检测是最容易被写糙的地方。新手常见写法是拿指针坐标去跟每张卡片的矩形做碰撞，谁碰到算谁。这个写法的问题是：卡片有高度，指针可能落在两张卡片的交界处，或者落在卡片的下半部分但视觉上用户觉得自己还在上一张下面。

我用的判定是被拖拽卡片的中心线，而不是指针位置。具体来说，拖动时实时计算被拖卡片的中线 Y 值，遍历目标列里所有卡片的矩形，找到第一张“中线落在其上半部分”的卡片，插入到它前面；如果中线落在某张卡片的下半部分，就插入到它后面。这样即使指针压在卡片边缘，判定结果也稳定。

function findInsertIndex(pointerCenterY: number, rects: DOMRect[]): number { // rects 是目标列内所有卡片按视觉顺序排好的矩形 for (let i = 0; i < rects.length; i++) { const mid = rects[i].top + rects[i].height / 2; if (pointerCenterY < mid) return i; } return rects.length; }

跨列移动的判断更简单：用指针坐标去跟每个列容器的getBoundingClientRect()做水平区间比较，落在哪一列就换到哪一列。但要注意列容器可能很长，一屏放不下时需要横向滚动，滚动时矩形要重新算，不能在拖拽开始时算一次就缓存到底。我第一版就是缓存了，结果横向滚动之后整列判断全错位，排查了四十分钟才发现是缓存问题。

2.4 WIP 限制和状态流转：业务规则要放在提交前

看板类应用最容易加也最容易加错的是“每列最多 N 张卡”这个限制。加错的方式是把校验放在接口层，用户拖过去了、界面变了、接口报错弹窗，体验极差。

正确的位置是在松手计算落点之后、乐观更新之前做一次本地校验。如果目标列已经满了，拖拽过程中就把目标列高亮成不可放置状态（比如描边变红、占位符不出现），松手直接弹回原位，连请求都不发。这样用户在整个拖拽过程中就知道“这里放不进去”，不会等到松手才被拒绝。

function canDrop(targetColumn: Column, currentCount: number, movingFromSame: boolean): boolean { if (!targetColumn.wipLimit) return true; if (movingFromSame) return true; // 同列内挪动不增加计数 return currentCount < targetColumn.wipLimit; }

状态流转的规则同理。如果业务上规定“待办”只能流转到“进行中”，不能直接跳到“已完成”，那这条规则也要在落点计算时就拦掉，而不是靠后端返回错误码再提示。这条经验是我在一次演示中现场翻车换来的：当着十几个人的面把一个卡片从最左拖到最右，弹了个错误窗口，那个尴尬程度足够我记一辈子。

3. 实操过程：从生成骨架到可交付的完整链路

3.1 第一轮生成：需求描述怎么写才不返工

在快马平台里输入需求描述，写法直接决定生成质量。我一开始写了一长段“帮我做一个任务看板”，生成结果非常平庸：卡片是静态的、没有拖拽、数据结构就是一个数组。后来我改成结构化的三段式描述，效果立刻不一样。

我的描述模板是这样的：

角色与场景：一个 5-10 人小团队的内部任务看板，用于每日站会同步进度。 页面结构：顶部是筛选栏，主体是横向滚动的多列区域，每列有标题、计数、卡片列表。 数据要求：列有序、卡片有序且属于某一列、卡片包含标题/负责人/标签/更新时间。 交互要求：卡片可在列内排序、可跨列拖动，拖动时有跟随效果和占位提示。 技术约束：使用当前主流前端框架，状态管理用轻量方案，接口先用本地模拟。

关键在于把“数据要求”和“交互要求”单独拎出来说。生成式工具对结构化的输入响应明显更好，尤其是它知道你需要“有序”这个概念之后，产出的数组结构里会带上序号字段，省了我不少改造量。这不是玄学，是我试了四五次之后稳定复现的规律。

生成完之后别急着夸或骂，先做三件事：跑起来看能不能启动、看目录结构合不合你的习惯、看数据文件里字段全不全。能启动是底线，目录结构决定后面改起来顺不顺手，字段全集决定你要补多少活。我这次生成的骨架里字段少了version和updatedAt，这两个必须手补，因为后面做并发控制和“最近更新排序”都要用。

3.2 拖拽核心：用指针事件手写，别死磕旧方案

拖拽实现这块我踩过两个方向。第一个方向是用浏览器原生的 HTML5 拖放接口（dragstart/dragover/drop），好处是代码量少，坏处是移动端基本不可用，而且拖拽过程中的视觉样式几乎无法自定义，那个半透明的幽灵图你控制不了。第二个方向是手写指针事件（pointerdown/pointermove/pointerup），代码多一点，但桌面和触屏一套逻辑通吃，视觉完全可控。

我选第二个。核心代码大概是这样：

type DragState = { cardId: string; fromColumn: string; startX: number; startY: number; offsetX: number; offsetY: number; active: boolean; // 是否超过阈值 }; const DRAG_THRESHOLD = 5; function onPointerDown(e: PointerEvent, card: Card, el: HTMLElement) { const rect = el.getBoundingClientRect(); const state: DragState = { cardId: card.id, fromColumn: card.columnId, startX: e.clientX, startY: e.clientY, offsetX: e.clientX - rect.left, offsetY: e.clientY - rect.top, active: false, }; // 记住初始位置，用于失败回滚 cache.setState(state); el.setPointerCapture(e.pointerId); } function onPointerMove(e: PointerEvent, el: HTMLElement) { const s = cache.getState(); if (!s) return; const dx = e.clientX - s.startX; const dy = e.clientY - s.startY; if (!s.active) { if (Math.hypot(dx, dy) < DRAG_THRESHOLD) return; s.active = true; el.classList.add('dragging'); } el.style.transform = `translate3d(${dx}px, ${dy}px, 0)`; updatePlaceholder(e.clientX, e.clientY); autoScroll(e.clientY); }

几个必须注意的细节。setPointerCapture一定要加，否则快速拖动时指针移出元素，pointermove事件就断了，卡片会卡在半空中。translate3d的第三个参数补 0 是为了强制走 GPU 合成层，少了这个在某些浏览器上还是会走普通渲染路径。拖拽期间给body加user-select: none，不然会顺带把文字选中，屏幕上出现一片蓝色选区，很难看。

3.3 手感调优：自动滚动的阈值和速度怎么定

看板横向滚动是刚需，列多了以后一屏肯定放不下。拖拽到边缘时自动滚动，这个功能做不好会比不做还糟——要么滚不动，要么滚得像失控。

我的实现是两个参数：触发阈值和最大速度。触发阈值定 80 像素，意思是当拖拽位置距离滚动容器边缘 80 像素以内时开始滚动。这个值要略大于卡片高度（我的卡片是 64 像素高），否则用户还没意识到自己到边缘，页面就开始动了，会有被“抢走”的感觉。

速度的算法我用的是二次曲线，不是线性：

const EDGE = 80; const MAX_SPEED = 14; // px per frame function autoScroll(pointerY: number) { const container = scrollEl.getBoundingClientRect(); const distTop = pointerY - container.top; const distBottom = container.bottom - pointerY; if (distTop < EDGE) { const ratio = Math.max(0, (EDGE - distTop) / EDGE); container.scrollTop -= MAX_SPEED * ratio * ratio; } else if (distBottom < EDGE) { const ratio = Math.max(0, (EDGE - distBottom) / EDGE); container.scrollTop += MAX_SPEED * ratio * ratio; } }

为什么用二次而不是线性？线性速度的表现是：一进边缘区就以固定速度滚，用户感觉是“页面突然开始动”；越靠近边缘速度越快的二次曲线，用户感觉是“我推得越用力它滚得越快”，符合物理直觉。这个细节我调了三次才满意，前两次都是线性，用过之后总觉得哪里别扭，改成平方之后一下就对了。MAX_SPEED定 14 也不是随便写的，60 帧下每秒 840 像素，刚好是能快速跨越一整屏又不会让人眼花的速度。

3.4 落库与乐观更新：先改界面，失败再退回去

用户拖完一张卡，如果要等接口返回才更新界面，中间那段空白期（哪怕只有 300 毫秒）都会让人觉得“卡了”。所以必须做乐观更新：本地状态立刻改，请求后台异步发。

async function commitMove(card: Card, toColumn: string, newOrder: number) { const snapshot = { columnId: card.columnId, order: card.order }; // 1. 本地先改 store.applyMove(card.id, toColumn, newOrder); try { // 2. 带上版本号提交，后端做乐观锁校验 const res = await api.moveCard({ id: card.id, columnId: toColumn, order: newOrder, version: card.version, }); store.updateVersion(card.id, res.version); } catch (err) { // 3. 失败回滚到快照 store.applyMove(card.id, snapshot.columnId, snapshot.order); toast('这张卡片刚被别人动过，已恢复原位'); } }

这里的version字段就是用来做冲突检测的。后端在更新时检查数据库里的version是否等于请求里的version，不等就返回冲突，前端回滚并提示。这套机制不复杂，但能挡掉 80% 的并发覆盖问题。

请求失败的回滚一定要加动画，不能瞬间弹回去。我用的是 200 毫秒的过渡，视觉上是“卡片自己滑回原位”，比“啪一下位置变了”友好太多。这个 200 毫秒也试过别的值：100 太快看不出来发生了回滚，400 又显得拖沓，200 刚好。

注意：乐观更新 + 冲突回滚这套逻辑，一定要在开发阶段就把失败路径测通。做法很简单，在接口层加一个“随机失败 30%”的开关，然后疯狂拖拽两分钟。我第一版忘了测失败路径，上线第一天就遇到并发冲突，回滚逻辑里有个空指针，整个板面直接白屏。

3.5 部署与验收：四条硬指标决定能不能交付

部署这件事本身没什么可讲的，值得一提的是验收标准。我在马威斯里把这个需求拆成了四条可勾选的验收项，这四条规定死了“什么叫做完”：

第四条是纯经验换来的。移动端上不加touch-action: none，浏览器会把你的拖拽手势识别成页面滚动，表现就是手指按上去、页面往上滑、卡片纹丝不动。这个属性要加在可拖拽元素上，不是加在容器上。我第一次加错了地方，调试半天以为是指针事件没绑定成功。

4. 常见问题与排查技巧实录

4.1 拖拽相关的症状速查表

拖拽这类交互的特点是：能跑和好用之间隔着一堆细节，而且症状都很像。我整理了一张表，基本覆盖了我这两周遇到的全部问题。

其中“抖动闪回”是最常见的。它的成因不止一种，但排查顺序很固定：先看是不是用了left/top，再看是不是每帧都重建了 DOM 节点，最后看是不是拖拽元素本身也在参与排序计算。这三条排完，九成的抖动都会消失。

4.2 数据不一致：三种典型场景和对应解法

数据类问题比交互类问题更难排查，因为界面上看起来一切正常，只有刷新或者换个人打开才暴露。

第一种是顺序冲突。两个人几乎同时把卡片拖到同一列的同两个位置，两条写入的order值不同但都合法，结果取决于谁后写。你没法完全避免，能做的是保证最终一致性：每次拉取列表时按order排序，遇到order相同的就用updatedAt兜底，保证任何情况下顺序都是确定的。

第二种是跨列丢失。用户把卡片从 A 列拖到 B 列，界面过去了，但后端只更新了order没更新columnId，刷新后卡片回到 A 列。这类问题的根因通常是接口字段命名不统一，比如前端叫columnId、后端叫listId，序列化时被静默丢弃。我的处理办法是给接口加一层显式的字段映射，任何字段对不上直接抛错，不让它静默失败。

第三种是删除后的幽灵卡片。别人删了这张卡，你这边界面上还留着，拖一下报 404。这个要靠在拉取时对 404 做静默移除处理，而不是弹一个红色错误框吓用户一跳。

4.3 性能：卡片数量上去之后怎么不卡

一列五十张卡、五列共两百五十张，这是小团队看板的正常量级。这个量级下如果不做优化，拖动会明显掉帧。我用了三个手段。

第一，拖拽期间只渲染一份“跟随层”。被拖的卡片在跟随层里跟着指针动，原位置只留一个静态的占位块。这样就避免了“原位置卡片 + 跟随卡片”两份都在做动画。

第二，拖拽期间冻结非目标列的更新。拖拽过程中列内的插入位置会频繁变化，如果每次变化都触发整个板面的重新渲染，帧率必崩。我的做法是用一个独立的draggingId状态让列表组件跳过无关的重渲染。

第三，超过一定数量时上虚拟滚动。我的阈值是单列 80 张，超过就只渲染视口内的卡片。这个改造量不小，所以我先做了前两条，观察了一周发现两百多张还不卡，第三条就没上。优化要按实测来，不要按想象来，这是我踩过太多次的坑——提前做了一堆优化，结果瓶颈完全在别的地方。

4.4 独家避坑：三个只有真上手才知道的细节

第一个细节：拖拽结束到松手的那个瞬间，一定要先解绑指针事件再改数据。顺序反了会出现“改完数据、重新渲染、元素被替换，然后pointerup打在了新元素上”，表现是偶尔需要点两下才能继续拖。这个 bug 极其难复现，因为它跟渲染时机有关，我花了小半天才定位到。

第二个细节：从生成式平台拿到的骨架，如果它给你的拖拽是“每帧重新计算整个列表的顺序”，不要试图优化它，直接删掉重写。我试过在生成结果上打补丁，改了三个小时越改越乱，最后删掉重写只用了四十分钟。

第三个细节：站会投屏的时候，卡片字号和列宽要按“三米外能看清”来定，不是按“自己笔记本上好看”来定。我第一版按自己屏幕调的，投到会议室大屏上，标签字小得像蚂蚁，当场被问“这写的啥”。后来把卡片标题字号从 14 提到 16，标签从 12 提到 13，问题解决。

5. 团队落地：让看板真的被用起来

5.1 马威斯在流程里的定位：不是管理工具，是验收清单

工具本身不产生价值，产生价值的是“谁在什么节点看一眼什么东西”。我在马威斯里只建了三类任务，没有把整个研发流程搬进去。

一类是功能验收项，就是前面那张四条硬指标的表格，每条都写成可勾选的，验收人明确到具体的人。第二类是已知问题，专门记那些“不影响演示但迟早要修”的东西，比如某个边界情况下的排序不稳定。第三类是每日同步，每天站会前五分钟把当天要动的卡片挪到“进行中”，站会上只看这一列。

这个用法很朴素，但它解决了一个真实问题：以前需求都在聊天记录里，做完之后没人记得当初说好的是什么，只能靠“我觉得应该是这样”来争论。把验收项写下来之后，争论的宾语从“你做的对不对”变成了“这条勾没勾上”，会高效很多。

5.2 我踩过的几个坑和后面的扩展方向

第一个坑是一开始就把权限做太重。我第一版加了列级权限、卡片级权限、字段级权限三层，结果团队只有七个人，每次调整都要改配置，用了一周就没人愿意维护。后来砍到只剩“谁能删卡片”一条，反而没人抱怨。

第二个坑是以为所有人都喜欢拖拽。实际上有一部分人更习惯键盘操作——他们想看某个卡片，第一反应是在搜索框里输入，而不是去找。所以后面补了搜索和键盘快捷切换，比优化拖拽动画的价值大得多。

第三个坑是忘记做“撤销”。拖错了要拖回去，这是最反人性的设计。我后来加了一个“撤销上一次移动”的按钮，只保留最近一次操作，代码不到二十行，但它是我收到正面反馈最多的一个功能。这个经验我觉得挺通用的：用户对“我做错了”的恐惧，往往比“我做不快”更影响使用意愿。

后面如果要继续做，我打算加两块：一块是卡片上的时间线，记录谁在什么时候动过；另一块是按人筛选的视图，让每个人站会上只看自己的卡。这两块都不难，难的是想清楚“加了之后会不会让看板变得更重”——看板这类工具最大的敌人从来不是功能不够，而是信息密度失控，一屏塞了三屏的东西，最后谁都不想打开。

最后分享一个我觉得最值钱的小技巧：把拖拽的落点计算和实际的数据提交彻底分开写成两个纯函数，一个负责“松手时该落在哪”，一个负责“落点怎么变成数据变更”。这两个函数不依赖任何 DOM 和界面状态，可以单独写测试。我一开始没这么写，所有逻辑都在事件回调里，改一次要手动拖动验证一次，一天下来手指都酸了。拆开之后，改排序规则只要跑一遍测试，两分钟就知道对不对。