列表项排序设计：分数索引思想与实践

以「课程章节排序」为例，说明一种无需大规模重写序号的列表排序方案：通过「前驱 ord + 后继 ord」在数轴上插空，用**分数索引（Fractional Indexing）**的思想实现 O(1) 插入与拖拽排序，并给出创建/更新时的业务规则、边界处理以及可复用的业务场景。

前端效果：

一、排序的核心思想

1.1 问题：为什么不用 1、2、3、4…

若列表顺序用连续整数 1、2、3、4… 表示：

• 插入：在 2 和 3 之间插入一条，需要把 3、4、5… 全部 +1，更新量大，且高并发下易冲突。
• 拖拽：把第 5 条拖到第 2 条前面，同样要批量更新后面所有项的序号。

当列表很长、或排序操作频繁时，这种「连续整数序号」方案会带来大量写操作和锁竞争。

1.2 思路：在数轴上「插空」

不追求序号连续，而是把每一项对应到实数轴上的一个点，顺序即数轴上的先后关系：

• 在 A 与 B 之间插入：新项的 ord 取 A 与 B 的 ord 的中间值，例如 ord = (ordA + ordB) / 2。
• 在 某一条之后插入：新项的 ord = 前一条的 ord + 一个固定步长，例如 ord = preOrd + 1000。
• 放到最后：新项的 ord = 当前最大 ord + 步长。
• 放到最前：新项的 ord = 0（或约定一个最小基准）。

这样：

• 插入/移动通常只改当前这一条的 ord，不需要批量更新其他项。
• 顺序由「数轴上的大小关系」决定，与是否连续整数无关。

这就是 Fractional Indexing（分数索引） 的简化实现：用稀疏的、可再分的数值表示顺序，通过「取中间值」在任意两点之间插入，避免全局重排。

1.3 本方案中的具体约定

• 使用整数 ord，顺序按 ORDER BY ord ASC。
• 中间插入：ord = (preOrd + nextOrd) / 2（整数除法）。
• 前驱后插入：ord = preOrd + ORD_STEP（如 1000）。
• 追加到末尾：ord = max(ord) + ORD_STEP；无任何项时 ord = ORD_STEP。
• 置顶：ord = 0。

步长 ORD_STEP 抽成配置常量（如 1000），既保证新项与已有项不重叠，又为将来在两点之间多次插入留出空间（多次取半后可能需要在某次触发「重算序号」或扩大数值域，这是后续优化点）。

二、创建时的业务规则（新增章节）

创建时不直接传 ord，而是通过前驱/后继的 ord 表达「插在哪里」，由后端统一计算新 ord。

业务要点：

• 新增接口只接受 courseId、title、可选的 preOrd/nextOrd 等，不暴露「直接写 ord」，避免前端传错导致顺序错乱。
• 同一课程下的 ord 只在「当前课程」内取 max，不同课程互不影响。
• 使用分布式锁（如按管理员 + 课程维度）保证同一课程下的创建/排序并发安全。

三、更新时的业务规则（拖拽/改顺序）

更新时既支持「按位置语义」的排序，也支持直接改 ord（如后台批处理）。

与创建的差异：

• 仅传 nextOrd：表示「把当前项放到 nextOrd 对应的那条前面」，即置顶，因此 ord = 0。这样前端把列表最后一条拖到最前时，只需传 nextOrd = 当前第一条的 ord，无需 preOrd。
• 支持直接传 ord，便于管理端或脚本批量调整顺序。

四、边界与实现细节

4.1 空列表与首项

• 创建且不传 preOrd/nextOrd：max(ord) 无值，则 ord = 0 + ORD_STEP，即第一条为 1000。
• 更新且仅传 nextOrd：置顶，ord = 0。若原来就有 ord=0 的项，列表里会出现两个 0，顺序按 id 或更新时间等次要字段区分；也可在「仅 nextOrd」时改为 min(ord)-1 或做一次轻量重排，视产品需求而定。

4.2 整数取半与精度

• (preOrd + nextOrd) / 2 为整数除法。若 preOrd=100, nextOrd=102，得到 101；若 100 与 101 之间再插，得到 100，与 100 重复。此时需要：
  • 要么接受「相等时按 id 等次要字段排序」；
  • 要么在检测到 ord 冲突或间距过小时触发局部或全局重算（例如按当前顺序重新赋 1000、2000、3000…），避免长期取半导致精度用尽。

4.3 步长常量

• ORD_STEP（如 1000）抽成配置常量，便于：
  • 统一「前驱后插入」与「追加到末尾」的步长；
  • 未来若列表极长或插入极频繁，可调大步长或配合重算策略。

4.4 并发与锁

• 创建/更新顺序时对「同一课程」或「同一管理员+课程」加锁，避免并发生成相同 ord 或 max(ord) 读不准。

4.5 日志与可观测性

• 在计算 ord 的分支打 debug 日志（preOrd、nextOrd、计算得到的 ord），便于排查顺序错乱和边界问题。

五、适用场景与复用建议

同一套「前驱 ord + 后继 ord + 步长」的思想，可用于所有用户可拖拽排序、且希望避免大规模更新的列表场景，例如：

复用要点：

• 表结构：列表项表有 ord（或 sort_order）字段，同一「父」维度内排序（如 courseId、menuId、boardId）。
• 创建：支持可选的 preOrd/nextOrd，不传则追加到末尾（max(ord)+STEP）。
• 更新：支持 preOrd、nextOrd、以及「仅 nextOrd 表示置顶」的语义；可选保留直接传 ord 的能力。
• 步长：统一常量，便于调优与重算。
• 边界：明确空列表、置顶、取半冲突时的策略（接受相等或触发重算）。

六、小结与启发

• 排序的本质是「在有序数轴上找一个位置」；用稀疏的、可插空的 ord，而不是连续整数，能把插入/移动的代价从 O(n) 降为 O(1)，并减少锁竞争。
• 创建时用「前驱/后继」表达意图，更新时同样用 preOrd/nextOrd 表达「移到哪两个之间」或「放到前一个后面/放到最前」，接口语义清晰，前端拖拽只需传前后项的 ord。
• 边界要显式约定：空列表、置顶、取半导致相等时的处理，以及步长与必要时重算序号。
• 将步长与规则抽成常量和独立方法，便于在不同业务（章节、菜单、看板等）中复用，形成可积累的「列表排序」技术方案。