统一拖拽图文只收到一半UDMF 多 Entry 的类型协商、校验与失败回滚从浏览器或富文本页面拖一段“文字 两张图片”到应用文字出现了第二张图却因格式不支持而失败用户再次拖入后文字又重复一份。官方统一拖拽指南明确指出图文混排应按 UDMF 多 Entry 处理。工程上最容易漏掉的是多条记录属于一次用户意图不能把每条记录当成互不相关的成功。验证边界本文依据华为开发者官网截至 2026-09-25 可访问的资料整理。文中的状态机、去重器和坐标计算已经在 Node.js 宿主环境执行断言当前本机仍是 API 24 SDK且没有连接 HDC 真机因此不把这些断言写成 API 26 编译或真机实测。涉及窗口、拖拽和跨设备能力的正式交付仍需在 API 26 SDK、模拟器或对应真机上补齐接口编译、交互录像与日志证据。先把失败链画出来只读取第一条UnifiedRecord会静默丢数据边读边写业务库则在中途失败时留下半成品。更隐蔽的问题是来源应用可能同时提供 HTML、纯文本和图片的多个表示目标端如果不做类型协商会把同一内容导入两遍。复现时要分别测试完整支持、部分不支持、同一内容多表示和中途取消。协议必须携带什么先扫描全部 Entry按目标能力选择每个逻辑内容的最佳表示再生成导入计划。计划阶段只校验类型、大小、数量和权限不写业务库所有必需项通过后才一次提交。可选项失败可以降级并记录必需项失败则整体回滚。用 dragSessionId 与内容摘要建立幂等键防止用户重试造成重复。type RecordKindtext|html|image; interface Entry { logicalId:string; kind:RecordKind; bytes:number; required:boolean } export function choose(entries:Entry[], supported:SetRecordKind): Entry[] { const rank:RecordKind[][html,image,text]; const groupsMap.groupBy(entries,ee.logicalId); return [...groups.values()].map(grouprank.map(kgroup.find(ee.kindksupported.has(k))).find(Boolean)) .filter((x):x is Entry!!x); } export function canCommit(all:Entry[], chosen:Entry[]):boolean { const idsnew Set(chosen.map(xx.logicalId)); return all.filter(xx.required).every(xids.has(x.logicalId)); }案例一HTML 与纯文本代表同一段说明目标端支持富文本时选择 HTML纯文本只作为降级表示不应再创建第二段。导入计划保存 logicalId、选中类型和原始来源用户撤销时按一次事务删除而不是逐条猜哪些内容来自本次拖拽。案例二两张图片中一张超过大小上限若图片都被标记为必需项计划阶段直接拒绝并列出超限文件不先插入文字若超限图片是可选附件可以提交文字和第一张图但必须给出明确的部分导入提示并把结果写入同一个 session 记录。与常见方案对比观察项容易写错更可靠的处理记录读取只取第一条 Record先扫描全部 Entry类型选择支持什么就全导入同一 logicalId 只选最佳表示写入时机边解析边写数据库计划通过后一次提交重试处理用户重拖就再插入sessionId 内容摘要幂等多 Entry 拖拽本质上是小型数据导入协议。计划与提交分离后应用可以提前显示将导入哪些内容、哪些会降级失败也不会污染业务数据。这套封装还能复用到剪贴板粘贴和文件批量导入。上线前协议检查扫描全部 Entry 并识别多表示。必需项与可选项策略明确。大小、数量和类型在提交前校验。一次拖拽只有一个事务与幂等键。部分成功必须有可见提示和可撤销记录。官方资料与适用范围统一拖拽多设备通用适配指南图文拖拽不是“能拿到几条就存几条”。先协商表示、再验证完整性、最后一次提交用户的一个动作才会得到一个可解释的结果。