拖拽中需用JS监听dragstart/dragend动态添加/移除is-dragging类或data-dragging属性来实现视觉反馈，避免依赖:focus-visible、误用选择器或在dragover中频繁操作，确保状态精准绑定被拖元素本身。
拖拽过程中元素没有视觉反馈？别用 :focus-visible
:focus-visible 只响应键盘聚焦（比如 Tab 切换），和拖拽完全无关。浏览器不会在 dragstart 或拖拽中自动给元素加 focus，更不会触发这个伪类。强行依赖它，等于守着错误信号等反馈。
真实场景里，你需要的是「拖拽进行时」的即时状态标识——而原生 drag 事件本身不改变元素 class 或 attribute，得靠 JS 主动标记。
- 监听
dragstart，给被拖元素加临时类名，如is-dragging - 必须同时监听
dragend清除该类，否则状态残留（尤其跨容器拖拽失败时） - 避免用
draggable="true"后直接选[draggable="true"]——这会匹配所有可拖元素，而非当前正在拖的那个
如何安全添加/移除 is-dragging 类而不影响性能
频繁增删 class 本身开销不大，但若在 dragover 或 dragenter 中误操作，可能引发重排或样式抖动。关键是「只动被拖元素本身」，别波及目标区或父容器。
典型写法：
立即学习“前端免费学习笔记（深入）”；
element.addEventListener('dragstart', (e) => {
e.target.classList.add('is-dragging');
});
element.addEventListener('dragend', (e) => {
e.target.classList.remove('is-dragging');
});
- 用
e.target，不是e.currentTarget——确保是实际被拖的 DOM 节点（比如内部图标触发拖拽时，target 是图标，不是外层卡片） - 不要在
dragover里重复加 class，它每毫秒触发多次，极易导致样式反复计算 - 如果元素有 transition，建议对
is-dragging单独禁用动画：.is-dragging { transition: none; }，避免拖拽卡顿
IE/旧版 Safari 不支持 dragstart？用 data-dragging 属性更稳
某些老版本浏览器对 dragstart 的事件冒泡或 target 行为不一致，classList 操作可能失效。改用 HTML attribute 更可靠，CSS 也能直接响应。
- JS 中用
e.target.setAttribute('data-dragging', 'true')和e.target.removeAttribute('data-dragging') - CSS 写成
[data-dragging="true"] { opacity: .6; }，兼容性比类名略好 - 注意：attribute 值必须是字符串，
data-dragging="1"和data-dragging=""在 CSS 选择器里行为不同，统一用明确值
拖拽嵌套结构时，为什么子元素加了 is-dragging，父元素样式却没变
因为 is-dragging 只加在被拖节点上，而你写的 CSS 可能是 .parent.is-dragging .child 这种后代选择器——它要求父元素自己带类名，但实际被拖的是子元素。
- 要么把样式写成
.is-dragging, .is-dragging *（慎用，可能影响深层子元素） - 要么用属性选择器配合 JS 设置父级：在
dragstart中向上找最近的容器并加类 - 最干净的做法：让拖拽逻辑从容器层发起，即只允许点击容器空白处拖拽，避免子元素单独触发
真正难的不是加样式，是判断「谁该承担拖拽状态」——DOM 结构越深，越容易在父子关系里漏掉这一层归属意识。
