真正引发dropzone高亮错乱的是dragenter/dragleave在嵌套结构中被多层捕获且未隔离，正确做法是仅在外层容器绑定事件并设子元素pointer-events: none。
事件冒泡本身不会直接导致 DropZone 高亮错乱，真正引发视觉状态混乱的，是 dragenter/dragleave 事件在嵌套结构中被多个层级同时捕获，而开发者未做事件路径隔离或状态归一化处理。
嵌套容器监听 dragenter/dragleave 会触发多次高亮
当文件拖入一个外层容器（如 <div class="dropzone">），而该容器内部还有子元素（比如提示文字、图标、边框 div），浏览器会依次派发 <code>dragenter 到子元素 → 父容器 → 更高层级。如果所有层级都监听了 dragenter 并统一加 class="highlight"，就会出现：
- 鼠标刚进入外层区域时，父容器高亮；
- 接着鼠标划过内部
<p>拖拽文件到这里</p>，该p元素也触发dragenter，再次加高亮类； - 但
dragleave却可能只从p触发一次，而父容器没收到对应离开事件——因为鼠标其实还在父容器内，只是离开了子元素； - 结果：子元素移除了高亮，父容器却还挂着，或者反过来，高亮残留、反复闪动。
子元素拦截事件导致 dragleave 不准确
子元素（尤其是带文字、图标、padding 的元素）默认会响应拖拽事件。一旦它捕获到 dragenter，就会打断“父容器是否真正被进入”的判断逻辑。更严重的是：dragleave 在跨子元素移动时频繁触发，但浏览器不保证它总能精准反映“是否已离开整个 DropZone 区域”。
- 例如：鼠标从左上角图标拖向右下角文字，会先后触发图标
dragleave→ 文字dragenter； - 此时若用
dragleave移除高亮，就会误判为“用户已离开 DropZone”，提前取消样式； - 实际用户根本没移出容器边界，只是在内部移动——高亮就断了。
正确做法：只在最外层容器处理高亮，子元素禁用事件捕获
DropZone 的高亮应代表“整个可投放区域是否处于活跃状态”，这个状态只属于容器本身，不该由内部任意子节点决定。实现方式很明确：
- 仅给最外层容器绑定
dragenter和dragleave，并用一个布尔标志（如isDraggingOver）统一管理高亮状态； - 所有子元素（
<p></p>、<svg></svg>、<span></span>等）加上style="pointer-events: none"，确保它们不拦截拖拽事件，让dragenter/dragleave始终准确反映鼠标是否在容器边界内； -
dragenter中设isDraggingOver = true并添加高亮类； -
dragleave中不能直接移除——要结合e.relatedTarget判断是否真的移出了容器，或改用计时器防抖（如延迟 30ms 后检查是否仍在容器内）。
为什么 dragover 不适合做高亮依据？
dragover 每几十毫秒触发一次，频率太高，不适合用于开关视觉状态。它核心作用是“告诉浏览器允许投放”，必须调用 e.preventDefault()；而高亮是 UI 反馈，应由边界事件（dragenter/dragleave）驱动。混用会导致：
- 重复添加/移除 class，触发大量重绘；
- 鼠标悬停不动时，
dragover仍持续触发，UI 状态抖动； - 无法区分“刚进入”和“正在拖动中”，失去语义清晰性。
