更新：根据受欢迎的要求,这些是技术原因：

>当鼠标下方有节点时,节点将获取所有鼠标事件.
>鼠标事件冒出父链.
>现在假设您使用鼠标移动此节点 – 此节点将始终获取所有鼠标事件.
>这意味着任何其他节点(例如目标)都不能获取鼠标事件,除非它是移动节点的父节点.通常情况并非如此.

但我知道其他人可以做到！它应该是可能的！是的,有可能……原则上：

>让我们注册所有目标节点.
>让我们直接在最顶层的父级(文档)上捕获相关的鼠标移动事件.
>当我们检测到拖动操作时,让我们执行以下操作：

>计算所有目标的几何(边界框).
>在每次鼠标移动时,检查当前鼠标位置是否与目标重叠. “A”学生的奖励积分：检测与其他节点的重叠,例如,当目标由于美观原因而部分模糊时,并正确处理这种情况.
>如果当前鼠标位置与目标重叠,让我们启动“可以放弃”操作,显示一些提示,以便最终用户知道她现在可以放弃.

为什么Dojo不这样做？出于多种技术原因(最后我们到达那里！)：

>在大多数浏览器中,节点的几何计算都是出了名的错误.只要涉及表格或任何其他非平凡的放置方式,您就不能100％确定边界框是否正确.
>几何计算是一项昂贵的操作,我们必须在所有目标的每次拖动操作中至少执行一次,假设在拖动操作期间不能进行任何更改(并非总是如此).浏览器可能会出于多种原因重排节点⇒它可以移动/调整现有目标的大小,因此我们必须保持警惕.
>通常,计算出的方框保存在列表中⇒检查交叉点列表是否为O(n)(线性)⇒随着目标数量的增加不能很好地扩展.
>所有鼠标事件处理程序都应该很快,否则浏览器的鼠标事件处理设施可能会“损坏”,从而导致不可预测的副作用.请参阅前面的几点,了解鼠标事件处理速度慢的原因.
>改进线性搜索是可能的,可以使用2D空间树,但它会导致更多(更多)JavaScript代码⇒更多的东西要在客户端下载⇒通常它不值得.

我怎么知道的？因为Dojo过去常常在早期版本中使用这种拖拽方式,而且我在上面描述了生病和疲惫的战斗问题.任何改进都是一场艰苦的战斗,这增加了代码大小.最后,我们决定不再重新发明和复制已经在浏览器中构建的机制.浏览器几乎完成相同的工作：计算节点的几何,查找底层节点,并适当地调度鼠标移动事件.

当前实现不使用鼠标移动事件,也不计算几何.相反,它依赖于拖动开始后目标检测到的鼠标过/关事件.它工作可靠,可以很好地扩展.

这个故事的另一个缺点是：Dojo将目标视为容器 – 一个非常常见的用例(购物车,重新排列项目,编辑层次结构).目前实现了线性容器和通用树,可以使用自定义容器.拖放时,您可以在目标容器内的适当位置查看和拖放拖动的项目,将它们插入现有项目之间.使用几何计算和检查实现此功能将非常昂贵.