原生 drag/drop 实现列内任务排序需手动处理 dragover/drop 位置逻辑，通过 getboundingclientrect 判断鼠标 y 坐标确定插入点，避免依赖 datatransfer 传数据；跨列拖拽须确保目标列容器监听事件并用 closest 定位，禁用 sortablejs ghost 模式以防布局错位，框架中需注意状态更新与 dom 同步时机。
用原生 drag / drop 事件实现列内任务排序
原生拖拽 API 是最轻量、兼容性最好的起点，但默认行为不支持“同列内排序”，必须手动干预 dragover 和 drop 的位置逻辑。关键不是靠 dataTransfer 传数据，而是靠 event.target 定位插入点。
实操建议：
- 给每个任务卡片（
<li>或<div class="task">）设 <code>draggable="true"，并监听dragstart存储被拖项的id或索引 - 在列容器（如
<ul class="column"></ul>）上监听dragover，立刻调用event.preventDefault()，否则drop不会触发 -
drop触发时，遍历当前列所有子任务元素，用element.getBoundingClientRect()判断鼠标 Y 坐标落在哪个元素的中线以上/以下，决定插入位置 - 避免直接操作 DOM 序列：先从数组中移除原任务，再用
splice(index, 0, task)插入，最后批量重渲染（或用insertBefore精确插入） - 列容器统一加
class="kanban-column"，并在其上绑定dragover和drop，不要绑定到内部子元素 - 在
drop处理函数里，用event.target.closest(".kanban-column")向上找最近的列容器，确保拿到正确上下文 - 拖拽开始时，把源列 ID 存进
dataTransfer.setData("text/plain", sourceColumnId)，drop时读取，用于区分“移动”还是“复制” - 视觉反馈很重要：在
dragenter时给目标列加class="drag-over"，dragleave时移除，避免用户无法判断是否悬停成功 - 如果选
SortableJS，必须关掉ghost：ghostClass: ""，改用chosenClass高亮被拖项，靠onMove回调手动计算插入索引 - 启用
swapThreshold: 0.5（默认是 0.6），让跨列交换更灵敏 - 列容器必须设
group: { name: "kanban", pull: true, put: true }，否则跨列不生效；但注意pull: "clone"会意外复制而非移动 - 移动端兼容差：需额外配
forceFallback: true+fallbackTolerance，否则 iOS Safari 上拖拽极易中断 - 不要在
drop里直接修改响应式数据后立刻查 DOM 位置；先用Array.splice更新本地数组，再用nextTick（Vue）或useEffect（React）等 DOM 更新后回调里处理视觉校准 - React 中避免用
useState存整个任务列表，改用useReducer或Immer，保证每次更新都生成新引用，防止列表重渲染失效 - 给每个任务加唯一
key（如task.id），且不要用索引；否则排序后 key 不变，框架会复用旧 DOM 节点，导致拖拽视觉错乱 - 调试时打印
event.clientX / clientY和目标元素getBoundingClientRect()，确认坐标系是否一致——滚动容器没设position: relative会导致getBoundingClientRect基准偏移
跨列拖拽时如何识别目标列和位置
跨列拖拽失败的常见原因是：目标列容器没监听 dragover，或未阻止默认行为；更隐蔽的问题是，drop 事件的 target 往往是子元素（比如任务卡片里的标题），而不是列容器本身。
实操建议：
为什么不要用 SortableJS 的 ghost 模式做看板
SortableJS 默认开启 ghost（拖拽时显示半透明副本），它依赖 position: absolute 定位，会脱离文档流——当列高度不固定、有 CSS Grid/Flex 布局时，ghost 元素常错位或消失，且无法准确反映真实插入位置。
实操建议：
React/Vue 中状态更新与 DOM 同步的时机陷阱
框架里拖拽的典型问题不是“拖不了”，而是“拖完状态变了，但 DOM 没动”或“DOM 动了两次”。根源在于：原生拖拽事件发生在框架渲染周期之外，setState 或 ref.value = ... 不会立即更新 DOM，而后续的 dragover 又基于旧 DOM 计算位置。
实操建议：
drop 事件里收口，且不能依赖框架生命周期。DOM 位置计算、事件委托层级、移动端 touch 适配，三者只要漏一个，用户就会觉得“卡住”或“插错位置”。
