拖拽防重必须前后端协同：前端用状态锁+视觉反馈阻断误操作，后端通过幂等键（用户+目标+内容哈希）原子校验业务唯一性，确保同一拖拽操作仅生效一次。
拖拽文字内容本身不触发表单提交，真正要防的是「拖拽后触发的保存动作」——比如把文字拖进某个区域，松手时自动调用 fetch() 或 submit()。这类操作极易因用户快速拖放、多次松手、页面卡顿而重复触发，仅靠前端节流远远不够，必须搭配后端幂等校验。
为什么拖拽场景下节流容易失效
节流（throttle）按固定时间间隔放行一次请求，但拖拽松手事件（drop）可能在极短时间内密集触发（如误触、多点触控、调试工具反复触发），且每次触发携带的业务参数（如目标容器 ID、文字内容 hash）可能不同，导致节流无法识别“逻辑重复”。更麻烦的是：用户拖一次、松手两次，节流只拦住第二次请求，却放行了两个语义相同的操作。
- 节流函数若只依赖时间戳，无法感知业务上下文是否重复 —— 比如两次拖拽都落到
div#notes且内容完全一致，这应视为重复，但节流不会比对 - 前端无法可靠获取服务端状态，比如某条笔记是否已存在、库存是否已扣减，节流挡不住“合法但冗余”的请求
- 移动端 touchend 事件易被误触发，节流 delay 设为 500ms 仍可能漏掉相邻松手
后端必须校验「业务唯一性」而非只看 token
拖拽保存不是传统表单，没有天然的 token 字段可嵌入。你得把幂等标识从客户端带上来，并在服务端做原子判断。关键不是“这个请求有没有 token”，而是“这次拖拽操作的结果，是否已在数据库中体现”。
- 客户端生成幂等 key：
md5($userId . $targetId . $contentHash . $timestamp)，其中$contentHash是拖拽文本的sha256或截断后的substr(md5($text), 0, 16)，避免长文本影响性能 - 服务端收到后，先查
SELECT id FROM drag_logs WHERE idempotent_key = ? AND status = 'success'，命中则直接返回200 { "code": 0, "msg": "已保存" }，不执行任何业务逻辑 - 没命中才走正常流程：开启事务 → 写业务表 → 插入
drag_logs记录（idempotent_key+status = 'success'）→ 提交 - 不要用
INSERT IGNORE替代查询，它不返回是否插入成功，无法区分“是第一次存”还是“已被别人存过”
前端配合：禁用 + 状态锁，不是只靠节流
节流只是辅助，真正阻断要靠状态锁和视觉反馈。拖拽松手那一刻，UI 必须立刻给出确定响应，否则用户会下意识再拖一次。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
立即学习“PHP免费学习笔记（深入）”；
- 监听
dragend和drop后，立即设置一个全局锁变量isDraggingSaving = true，后续所有拖拽松手事件开头就判断if (isDraggingSaving) return - 按钮或目标区加 loading 状态：比如给
div#notes加data-saving="true"并配 CSS[data-saving="true"]::after { content: "保存中…"; } - fetch 成功后清锁：
.finally(() => { isDraggingSaving = false; targetEl.removeAttribute('data-saving'); })，失败也要清，否则卡死 - 别用
onclick="return false"或单纯button.disabled = true，拖拽目标通常是 div，要靠 JS 状态控制，不是 DOM 属性
刷新/后退导致的重复提交怎么破
用户拖完保存成功，按 F5 刷新页面，浏览器重发上次 drop 请求 —— 此时后端幂等 key 还在，查 drag_logs 能拦截，但前端不知道，仍显示空白或报错。必须让后端返回明确语义，前端据此更新 UI。
- 后端校验幂等 key 命中后，不能只返回 HTTP 200，必须带字段
"already_exists": true - 前端 fetch 收到该字段，就主动把对应文字块标记为「已同步」，比如加 class
synced、置灰拖拽手柄 - 如果拖拽目标是富文本编辑器，还要防止光标位置错乱：保存成功后，用
range.cloneContents()缓存当前选区，恢复时用range.insertNode()补回，而不是粗暴 reload - 别依赖
history.replaceState()隐藏 URL，它解决不了后退再拖的问题；真正可靠的只有服务端幂等记录 + 前端状态同步
拖拽防重的核心不是“拦住多少次请求”，而是“确保最终状态只变更一次”。后端幂等日志表必须带业务上下文字段（用户、目标、内容摘要、时间），且索引建在 (idempotent_key, status) 上；前端状态锁和视觉反馈缺一不可 —— 否则用户永远不知道“刚才那一下，到底算不算数”。
