dragstart是唯一可靠的拖拽开始信号，浏览器严格按事件流区分点击与拖拽：draggable="true"元素在鼠标按下并移动≥2px时触发dragstart，否则仅触发click；两者互斥，不可共存于同一操作。
dragstart 事件触发即代表用户意图拖拽
浏览器不会凭空判断“这是点击还是拖拽”，而是严格按事件流来区分：只要元素设置了 draggable="true"，鼠标按下并轻微移动（通常 ≥ 2px），就会触发 dragstart；没移动就松开，则只触发 click。两者互斥，不存在“先 click 再 dragstart”的情况。
关键点在于：拖拽行为由浏览器底层判定，JS 无法在 mousedown 阶段提前预知用户是否要拖拽——所以不能靠监听 mousedown + 计时/位移阈值来模拟拖拽逻辑，否则会和原生拖拽冲突、覆盖或静默失败。
-
dragstart是唯一可靠的“拖拽已开始”信号，此时可隐藏/禁用 click 相关逻辑（比如取消绑定的click事件监听器） - 若同时需要响应点击（如双击编辑、右键菜单），必须确保
click事件监听器不干扰dragstart——不要在dragstart里调用e.preventDefault()，否则会阻止后续的click - 避免给同一元素既设
draggable="true"又手动实现 mousedown+mousemove 拖拽，会导致两个拖拽系统打架，行为不可预测
如何让点击和拖拽共存不打架
常见需求是：单击选中、双击编辑、拖拽移动。这时不能靠“取消 click”来保拖拽，而要利用事件自然隔离机制。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 保持
draggable="true"，让原生拖拽接管拖动行为；所有拖拽逻辑写在dragstart/drop中 - click 处理放在独立监听器里，不做任何
preventDefault()或stopPropagation()干预 - 如果点击后需高亮但拖拽时不希望高亮，可在
dragstart中加 class（如is-dragging），CSS 里写.target:active, .target.is-dragging { opacity: 0.7; }，再在dragend清掉该 class - 注意：
dragstart后紧跟着的click会被浏览器自动取消（这是规范行为），所以别依赖“拖完立刻点一下”来触发 click
移动端没有 dragstart？得换思路
iOS Safari 和部分安卓 WebView 不支持原生 draggable 属性及拖拽事件，dragstart 根本不触发。这时候“区分点击与拖拽”就不是靠事件，而是靠手势识别。
可行路径：
- 放弃
draggable，改用touchstart→ 记录起始坐标 →touchmove中计算位移 → 超过阈值（如 10px）则进入拖拽模式，同时preventDefault()阻止滚动，并解绑后续click - 使用
PointerEvent（兼容性较好）统一处理pointerdown/pointermove，比分开写 touch/mouse 更可靠 - 别试图在移动端强行启用
draggable="true"，它在大多数移动浏览器中只是个摆设，连dragstart都不会派发
最易忽略的细节：click 和 dragend 的时机差
松手瞬间，浏览器先派发 drop 和 dragend，然后才可能派发 click（仅当未发生位移）。但实际中，因事件队列、渲染帧、防抖逻辑等影响，click 可能延迟几毫秒甚至被吞掉。
这意味着：
- 不要在
dragend里同步依赖click的副作用（比如弹窗、跳转） - 如果业务要求“拖完立即可点”，建议在
dragend后用setTimeout(..., 0)延迟一小步再恢复 click 监听，而不是立刻重绑 - 真正难处理的不是“怎么区分”，而是“拖拽结束后 UI 状态是否与 click 逻辑自洽”——比如拖拽一个卡片到新位置后，它是否还该响应点击？这个得靠数据层状态控制，不是靠事件顺序能解决的
