应使用 pending 状态锁住所有提交入口并配合 AbortController 中断未完成请求，而非仅依赖 submit_token 或禁用按钮；每次 drop 必须 preventDefault，改用 FormData + fetch 控制上传时机。
拖拽区域重复触发 submit 事件怎么办
文件拖拽提交本身不会自动触发多次 submit，但常见错误是把 drop 事件监听器绑在了表单内部，又没阻止默认行为或去重，导致用户一次拖入多个文件、或反复拖放时，submit() 被调用多次。
核心问题不是“拖拽”本身，而是你如何响应 drop：如果每次 drop 都直接调用 form.submit() 或触发 fetch，就等于手动制造重复提交。
- 必须在
drop回调开头加event.preventDefault()，否则浏览器可能执行默认上传（如打开文件）、甚至触发页面跳转 - 不要在
drop里直接调用form.submit()；改用new FormData(form)+fetch，才能控制请求时机和并发 - 若支持多文件，应合并为一次请求上传，而不是每个
File都发一个请求 - 避免监听
drop的同时又监听change（<input type="file">），两者可能被同一操作触发，造成双倍提交
用 pending 状态锁住拖拽提交入口
仅靠禁用按钮对拖拽无效——用户根本没点按钮。真正起作用的是 JS 层的执行锁，且必须覆盖所有触发路径（drop、change、手动点击按钮）。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 声明一个模块级变量
let pending = false，不是只在某个函数里定义 - 所有提交入口（
drop、change、submit事件）都先判断if (pending) return - 发起请求前设
pending = true，并在finally块中重置，确保失败也不卡死 - 配合 UI 反馈：禁用拖拽区域（
element.style.pointerEvents = 'none'）、加 loading 提示，让用户感知“已收下”
为什么不能只靠 hidden input + submit_token 防拖拽重发
submit_token 是防服务端重复处理的关键，但它对拖拽场景有盲区：如果前端在 drop 后没等响应就允许再次拖入，用户可能在第一个请求还没返回时，又拖第二波文件进来——此时第二个请求携带的是同一个 submit_token（因为 DOM 没刷新），后端会直接拒绝，但用户完全不知道发生了什么。
立即学习“前端免费学习笔记（深入）”；
-
submit_token必须随每次页面加载动态生成，不能由 JS 重复写入同一字段 - 若用
fetch提交，需在每次拖拽后重新请求新 token（不推荐，增加复杂度），或更合理地：把 token 生成逻辑后移到后端上传接口内部（即上传接口自己校验并消费 token） - 前端仍要靠
pending锁住 UI 层，否则用户体验断裂：token 被拒 → 用户以为网络失败 → 再拖一次 → 再拒 → 循环 - 注意：拖拽触发的
drop事件不经过表单原生submit流程，所以submit_token字段必须手动塞进FormData，不能依赖表单自动收集
AbortController 对拖拽重复提交有用吗
有用，但只在并发请求场景下生效，比如用户快速拖两次，第一次请求还没发完，第二次已经启动。这时候 AbortController 能中断前一个未完成的请求，避免“幽灵请求”在后台悄悄完成并污染状态。
- 每次拖拽开始前，先调用上一个
controller.abort()（如果存在） - 创建新
AbortController实例，传给fetch({ signal }) - 别忘了在
finally里清理引用：controller = null，防止内存泄漏 - ⚠️ 注意：
AbortController不影响已响应的请求，也不能替代pending锁——它只管“正在飞的路上”的请求，不管“刚点下去”的动作
drop、change、click、submit）统一收敛到同一个状态机里。漏掉任意一个，重复提交就可能从缝隙里钻出来。 
