关键不是“能不能加”，而是“怎么加才不打架”：拖拽依赖实时位置计算与DOM交互，虚拟列表依赖滚动容器与动态渲染，二者机制天然冲突，直接套用易致卡顿、错位、锚点丢失或滚动条跳动。
在看板（Kanban）拖拽场景中做列表虚拟化，关键不是“能不能加”，而是“怎么加才不打架”。拖拽本身依赖实时位置计算、频繁重排、事件监听和 DOM 交互，而虚拟列表又依赖滚动容器、固定高度、动态渲染和占位补偿——两者机制天然冲突。直接套用标准虚拟列表组件，往往导致拖拽卡顿、元素错位、拖拽锚点丢失或滚动条跳动。
拖拽与虚拟列表的核心冲突点
理解问题才能避开坑：
- 滚动容器被劫持：多数虚拟列表要求将列表内容包裹在固定高度的可滚动容器内，但看板拖拽常需整个看板区域自由滚动，或列容器各自独立滚动，结构嵌套深，scrollTop 计算易失准
- 高度不可控：看板卡片通常含动态内容（头像、多行文本、标签），高度不固定；而主流虚拟列表（如 vue-virtual-scroll-list）强依赖 itemHeight 固定值，否则 startIndex/endIndex 计算失效
- 拖拽态破坏渲染逻辑：拖拽过程中，被拖元素脱离文档流（如 transform + fixed 定位），虚拟列表的“可视区域判断”可能误判其为“已离开”，提前卸载；松手瞬间又需立即插入新位置，触发重渲染，若未缓存 DOM 或预占位，会出现闪烁或空白
- 事件穿透与层级错乱：虚拟列表用 padding-top 占位，若拖拽层 z-index 不高于该占位区，拖拽阴影可能被遮挡；scroll 事件监听若未节流或绑定在错误目标上，会与 dragover/drop 频繁争抢主线程
推荐分层实现策略
不追求“一个组件全包”，而是按职责拆解：
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- 列级虚拟化，非卡片级：每个看板列（column）单独启用虚拟滚动，列高固定（如 600px），列内卡片仍用 v-for 渲染，但只渲染当前可视段（例如最多 20 张）。列之间互不影响，拖拽卡片跨列时，仅更新数据索引，不触发整列重绘
- 拖拽锚点外置 + 静态占位：拖拽开始时，记录源卡片在列中的 index 和视觉位置（getBoundingClientRect）；在目标列 drop 区域上方插入一个 空 div 占位节点（height = 源卡片真实高度），保证滚动位置稳定；拖拽结束再移除占位、插入真实卡片，避免 layout thrashing
-
卡片高度缓存 + 动态修正：首次渲染每张卡片后，用 ref 缓存其 clientHeight 到 Map
；滚动时根据 startIndex 查表获取实际高度，用二分法累计偏移量替代固定 itemHeight 计算，支持变高卡片 - 滚动与拖拽事件解耦：禁用虚拟容器原生 scroll 监听，改用 passive: true 的 requestIdleCallback 节流更新可视范围；dragover 事件只更新 drop zone 样式和 hover 状态，不触发任何数据重算；drop 后用 nextTick + $nextTick 确保 DOM 更新完成再执行滚动定位
轻量级组合方案（无第三方库）
适合中等规模看板（单列 ≤ 500 卡片）：
立即学习“前端免费学习笔记（深入）”；
- 用 ref + onScroll + computed 手写列级虚拟范围计算，配合 v-show 控制卡片显隐（比 v-if 更轻）
- 拖拽用原生 HTML5 Drag & Drop API，避免依赖 draggable 库带来的额外 DOM 操作
- 所有卡片样式用 CSS containment: layout paint 隔离，防止一卡重排影响整列
- 滚动条使用 overflow: overlay（WebKit）或自定义 thin scrollbar，减少重绘面积
不复杂但容易忽略：拖拽流畅的本质，是让视觉反馈（shadow、hover、占位）与数据同步脱钩，优先保障 60fps 的视觉帧率，再确保数据最终一致。虚拟化在这里不是“渲染优化”，而是“渲染隔离”工具。
