根本原因是teleport将dom移至新容器导致拖拽依赖的定位上下文失效；应统一使用clientx/clienty和getboundingclientrect()获取视口坐标，避免transform干扰，重置弹窗根元素样式，并动态处理滚动同步。
在拖拽排序弹窗中使用 Teleport 后，坐标计算出错，根本原因不是 Teleport 本身“搞乱了位置”，而是它把 DOM 移到了新容器（比如 body），导致原本依赖父级定位上下文（如 transform、perspective、overflow: hidden）的拖拽逻辑失效。关键在于：Teleport 只改变渲染位置，不改变组件逻辑，但拖拽依赖的是真实 DOM 的层级和样式上下文。
确保拖拽起始坐标的参考系一致
拖拽开始时（mousedown 或 touchstart），需获取相对于视口（viewport）的绝对坐标，而不是相对于某个被 transform 的祖先节点。否则，当弹窗被传送到 body 后，原计算会因丢失父级偏移而偏差。
- 用
event.clientX / clientY获取初始点击点——它们天然以视口为基准，不受父容器 transform 影响 - 避免使用
element.getBoundingClientRect()后再手动加 offsetTop/offsetLeft，尤其当祖先存在 CSS transform 时，该方法返回值已受干扰 - 若需计算弹窗内某元素的拖拽锚点（如手柄），直接对目标元素调用
getBoundingClientRect()，它在 Teleport 渲染后仍有效，且结果是相对于视口的
修复 dragover/drop 时的坐标映射
拖拽过程中监听 dragover，判断光标落在哪个排序项上。如果排序列表本身也用了 Teleport（或嵌套在复杂布局中），需统一坐标系。
- 对每个候选排序项调用
el.getBoundingClientRect()，拿到其视口坐标范围（left,top,right,bottom） - 用
event.clientX / clientY与上述范围比对，而非尝试反向推算“在弹窗内部的相对坐标” - 不要假设弹窗 DOM 还在原组件树里——它已在
body下，但getBoundingClientRect()依然能正确反映它在屏幕上的真实位置
规避 transform 容器对 position: fixed/absolute 的干扰
很多拖拽库（如 SortableJS、vuedraggable）默认依赖 position: absolute 或 fixed 定位拖拽预览层。一旦祖先有 transform，这些定位会失效，导致预览层“飘走”。
- 将 Teleport 的
to目标设为body，并确保弹窗根元素自身无 transform/perspective/filter - 给弹窗最外层加
style="transform: none !important; perspective: none !important;"强制重置（必要时用:deep()或全局样式） - 若使用第三方拖拽库，检查其是否提供
fallbackTolerance或scrollSensitivity等适配 Teleport 的配置项；部分库（如@dnd-kit）原生支持 Teleport 场景
滚动容器与位置同步问题
当弹窗内容可滚动，且排序项跨多个可视区域时，拖拽预览的位置容易滞后或错位。
- 监听弹窗容器的
scroll事件，在滚动时主动更新预览元素的top偏移（基于当前 scrollTop + clientY 计算） - 避免仅靠 CSS
position: fixed固定预览层——它不会随弹窗滚动而动；改用position: absolute并动态设置top/left - 若弹窗本身是
position: fixed居中，其内部滚动不影响预览层坐标，此时只需保证预览层挂载在同级 Teleport 容器下（如都到body），避免嵌套传送
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
