前阵子排查一个鸿蒙应用里的粘贴问题用户反馈说在网页里明明选了一段带颜色、带加粗的标题复制到编辑器里颜色没了加粗也没了标题直接变成一行裸文本。最要命的是粘贴位置还偶尔不对明明光标在段尾结果内容插到了段首。这类问题就是典型的剪贴板保真问题。我做了两件事先把鸿蒙系统剪贴板这一层彻底捋了一遍再把编辑器侧的粘贴链路重新设计了一遍。这篇文章就是这次攻坚的完整记录重点写三个我实际踩到的坑以及最终沉淀下来的五段核心代码。希望给正在做鸿蒙富文本编辑器、笔记类 App、或者有自定义粘贴需求的同学一些参考。1. 鸿蒙剪贴板的数据模型以及保真到底保的是什么先说结论鸿蒙的系统剪贴板并不是一个简单的字符串缓冲区它内部是一套 PasteData 结构。一个 PasteData 下面可以挂多个 PasteDataRecord每条 record 都有独立的 MIME 类型。这意味着剪贴板在同一时间可以同时保存一份 HTML、一份纯文本、甚至一组 Uri 或 Want 数据。系统剪贴板 └── PasteData ├── Record 1: MIME_TEXT_HTML, p style\color:red\标题/p ├── Record 2: MIME_TEXT_PLAIN, 标题 └── Record 3: MIME_TEXT_URI, [file://... ]所以保真这个概念落到代码层面其实就是用户在源端复制时你是否把完整的数据类型写进了 PasteData你在目标端粘贴时是否按正确的优先级读回了数据并且在编辑器光标位置原样插入。1.1 PasteData 与 MIMETYPE剪贴板其实是一个小容器很多初学者容易把剪贴板理解成一个setText(getText())的简陋接口能贴能拿就行。但一旦做富文本编辑器这种理解会立刻翻车。鸿蒙的ohos.pasteboard模块中常用 MIME 类型有MIME 类型常量说明text/plainpasteboard.MIMETYPE_TEXT_PLAIN纯文本text/htmlpasteboard.MIMETYPE_TEXT_HTML富文本 HTMLtext/uri-listpasteboard.MIMETYPE_TEXT_URIUri 列表常用于图片/文件application/happasteboard.MIMETYPE_HAP应用包类型编辑器场景一般不用从网页、文档、或者系统级组件复制出来的内容大多数情况下会同时包含 HTML 和纯文本两条记录。HTML 是给富文本编辑器用的纯文本是给文本框、搜索框这类只能接收纯文本的场景用的。而保真攻坚的重点就是确保 HTML 这条管道不被截断。1.2 编辑器侧复制粘贴的三种入口鸿蒙应用里的粘贴操作并不是只有一种触发方式我实际调研下来编辑器场景通常有三个入口系统级上下文菜单触发的粘贴点击后由系统完成数据读取和文本写入。应用内自定义的粘贴按钮通过监听剪贴板数据后调用编辑器接口写入。WebView 内通过 JSBridge 调用原生去读写剪贴板。这三种入口的代码路径不同数据表现也不一样。系统级菜单粘贴往往不会给你任何拦截机会编辑器拿到的已经是系统处理过的内容自定义按钮则是你自己控制读写保真可控性最强WebView 方案则要看壳的封装是否把 MIME 类型都传给了原生层。所以做保真攻坚时第一步不是写代码而是确认你的编辑器走的是哪条粘贴路径。2. 三个坑格式降级、光标丢失、监听竞争2.1 坑一HTML 与纯文本没有成对写入富文本静默降级这个坑是我排查用户反馈时发现的第一现场。用户复制的是一条网页标题我用系统剪贴板工具看过里面明明有p标签、有 style 样式。但进入编辑器后读取到的只有纯文本HTML 记录凭空消失。我花了大半天时间最后排查出来的原因很无语项目的复制入口不止一个。部分列表项的长按菜单里有一段旧代码直接调用的是pasteboard.createData(pasteboard.MIMETYPE_TEXT_PLAIN, item.title)然后再setData()。这段代码执行时会用一份只有纯文本的 PasteData 整体覆盖掉系统剪贴板。也就是说用户复制到一半时还是完整的富文本但某个松散的联动逻辑又写了一次纯文本记录把之前的 HTML 记录顶掉了。这个问题的关键是setData()不是追加而是整体替换。只要有一次地方用单类型数据调用setData()剪贴板里所有类型的旧记录全部丢失。2.2 坑二粘贴位置光标偏移插入点永远是错的第二个坑出现在自定义粘贴按钮的路径里。我最初的实现思路是粘贴按钮被点击后先异步去getData()拿到 HTML 之后再插入到编辑器的光标位置。看起来没毛病但实际测试时频繁出现内容插到错误位置的情况。原因在于读剪贴板是异步操作耗时通常在几十到几百毫秒。用户点击粘贴按钮后如果编辑区焦点还在光标位置理论上不变但如果在此之前用户又点了一下编辑区或者输入法弹窗刚好调整了布局光标的 offset 已经不是原来的值了。更常见的是某些自定义编辑器在getData()回调返回之前已经把选区清空了我在回调里读到的caretOffset是 -1最后默认插入到了开头。后来我把方案改成了先锁光标再读数据最后插入才基本稳定。锁光标的方式不复杂关键在于时机必须在用户触发粘贴动作的同步阶段立刻记录光标位置不能等异步回调回来再取。2.3 坑三剪贴板 update 监听与异步读取的时序竞争第三个坑和 UI 状态有关。我希望工具栏的粘贴按钮能实时感知系统剪贴板是否有内容于是用了pasteboard.getSystemPasteboard().on(update, ...)监听剪贴板变化。初版代码在回调里直接getData()然后刷新按钮。实际运行一段时间后偶尔出现按钮状态和剪贴板内容对不上有时复制了新内容按钮始终置灰有时剪贴板已经没内容了按钮却一直高亮。我梳理时序后发现问题出在多个应用/模块同时写入剪贴板时的监听频率很高系统回调是异步的某些场景下getData()还在飞行途中另一次update又触发了旧回调携带的结果反而覆盖了新状态。也就是说回调本身没有串行保证我不能依赖最后一次回调为最终状态。正确做法是给数据读取加版本号或者做节流并且把update监听只当作提示不当作权威数据源。真正要获取内容时通过显式的读取动作去拿而不是依赖监听回调里的返回值。3. 五段代码从系统剪贴板到编辑器光标的完整管线下面这五段代码是我在项目里最终沉淀下来的核心实现。整条管线按照写入 → 读取 → 清洗 → 插入 → 监听五个环节拆分每段都能单独复用。3.1 代码段一成对写入 HTML 与纯文本不管你的复制源是网页、文档、还是系统组件只要内容可能带格式都必须同时写入 HTML 和纯文本两条记录。否则粘贴到纯文本输入框时用户看到的可能是一堆标签。import { pasteboard } from kit.BasicServicesKit; export async function writeClipboardWithHtml(html: string, plainText: string): Promisevoid { // 1. 用 HTML 作为主记录创建 PasteData const pasteData pasteboard.createData(pasteboard.MIMETYPE_TEXT_HTML, html); // 2. 追加一条纯文本 record确保纯文本场景也能正常粘贴 pasteData.addRecord(pasteboard.createRecord(pasteboard.MIMETYPE_TEXT_PLAIN, plainText)); // 3. 部分 API 版本支持设置 property声明本条 pasteData 包含的类型 // 旧版本不支持时用 try/catch 兜底不要影响主流程 try { const property new pasteboard.PasteDataProperty(); property.addMimeType(pasteboard.MIMETYPE_TEXT_HTML); property.addMimeType(pasteboard.MIMETYPE_TEXT_PLAIN); pasteData.setProperty(property); } catch (error) { console.warn(set property skipped, error:, error); } // 4. 整体写入系统剪贴板 const sysPasteboard pasteboard.getSystemPasteboard(); await sysPasteboard.setData(pasteData); }这里有一个细节createData()之后addRecord()是追加操作而不是新建覆盖。所以如果复制源本身就是 WebView建议把网页提取出来的 HTML 和document.body.innerText成对传入这个方法。纯文本不干净时宁可多清理一次也不要丢掉 HTML。3.2 代码段二按优先级读取HTML 优先纯文本兜底读取侧的核心原则是优先拿 HTML拿不到再退回纯文本。不要反着来否则富文本能力会被白白浪费。import { pasteboard } from kit.BasicServicesKit; export interface ClipboardContent { html?: string; text?: string; uriList?: string[]; } export async function readClipboardContent(): PromiseClipboardContent { const result: ClipboardContent {}; const sysPasteboard pasteboard.getSystemPasteboard(); try { const data await sysPasteboard.getData(); // 1. 优先尝试从主记录里直接取 Html 和 PlainText if (data.hasType(pasteboard.MIMETYPE_TEXT_HTML)) { const html data.getPrimaryHtml(); if (html) { result.html html; } } if (data.hasType(pasteboard.MIMETYPE_TEXT_PLAIN)) { const text data.getPrimaryText(); if (text) { result.text text; } } // 2. 如果主记录没有再遍历所有 record 逐一查找 if (!result.html || !result.text) { const records data.getRecords(); for (let i 0; i records.length; i) { const record records[i]; if (!result.html record.mimeType pasteboard.MIMETYPE_TEXT_HTML) { result.html record.html; } if (!result.text record.mimeType pasteboard.MIMETYPE_TEXT_PLAIN) { result.text record.plainText; } } } // 3. 处理图片/文件粘贴场景 if (data.hasType(pasteboard.MIMETYPE_TEXT_URI)) { result.uriList []; const records data.getRecords(); for (let i 0; i records.length; i) { const uri records[i].uri; if (uri) { result.uriList.push(uri); } } } } catch (error) { console.error(read pasteboard failed:, error); } return result; }hasType和getPrimaryHtml这些接口在部分 API 版本里返回值可能为空所以我加了主记录拿不到就遍历 record的兜底逻辑。实测下来不同的系统版本表现不完全一样有的版本主记录就够有的必须遍历才能拿到全部数据。3.3 代码段三把 HTML 清洗成编辑器内部结构带样式白名单直接从网页复制来的 HTML 通常充斥着大量无用标签、内联样式、甚至脚本。不能原样插进编辑器一方面排版会乱另一方面有安全风险。所以我在插入之前先做一次清洗。const STYLE_WHITELIST new Set([ color, background-color, font-weight, font-style, text-decoration, text-align, ]); const TAG_BLACKLIST new Set([ script, style, iframe, object, embed, ]); export function sanitizeHtml(rawHtml: string): string { if (!rawHtml) { return ; } // 1. 去掉黑名单标签及内容 let html rawHtml.replace(/script[\s\S]*?\/script/gi, ); html html.replace(/style[\s\S]*?\/style/gi, ); html html.replace(/iframe[\s\S]*?\/iframe/gi, ); html html.replace(/object[\s\S]*?\/object/gi, ); html html.replace(/embed[\s\S]*?\/embed/gi, ); // 2. 清洗每个开始标签的内联样式 html html.replace(/([a-zA-Z][a-zA-Z0-9]*)([^]*)/g, ( fullTag: string, tagName: string, attrs: string, ) { const tag tagName.toLowerCase(); // 非白名单标签一律还原成无属性标签 if (TAG_BLACKLIST.has(tag)) { return ${tagName}; } // 提取 style 属性里的声明 const styleMatch attrs.match(/style\s*\s*([^]*)/i); if (!styleMatch) { return ${tagName}; } const keptStyles styleMatch[1] .split(;) .map((item) item.trim()) .filter((item) { const prop item.split(:)[0]?.trim().toLowerCase(); return prop STYLE_WHITELIST.has(prop); }) .join(;); return keptStyles ? ${tagName} style${keptStyles} : ${tagName}; }); return html; }这段清洗逻辑并不是一个完整的 HTML parser对于生产环境我更推荐在 WebView 侧用 DOM API 去遍历节点。但在 Native 编辑器里需要一个轻量兜底时这个白名单方案足够解决 90% 的样式污染问题。3.4 代码段四在光标位置插入并维护选区清洗完 HTML 之后终于可以插入了。这一步的要点是锁光标、再插入、最后恢复选区。export interface EditorInsertContent { html: string; text: string; } export interface EditorLike { getCaretOffset(): number; setCaretOffset(offset: number): void; insertHtmlAt(offset: number, html: string, text: string): void; getSelection(): { start: number; end: number }; } export function insertContentAtCaret( editor: EditorLike, content: EditorInsertContent, ): void { // 1. 在用户触发粘贴的同步阶段记录光标位置 const caretOffset editor.getCaretOffset(); // 如果拿不到光标放弃自动插入让系统默认流程走 if (caretOffset 0) { return; } // 2. 在这里插入内容。真实项目如果基于 RichEditor // API 12 起可直接用 controller.insertText 之类接口 // 如果基于 WebView则是通过 evaluateJavaScript 插入并返回 offset。 editor.insertHtmlAt(caretOffset, content.html, content.text); // 3. 插入完成后把光标移动到内容末尾 const insertedLength content.text.length; const nextOffset caretOffset insertedLength; editor.setCaretOffset(nextOffset); }为什么要强调同步阶段记录光标位置因为剪贴板读取和插入是两个异步步骤。如果你的代码在await readClipboardContent()之后才取 offset这中间用户可能已经在编辑区产生了新的点击offset 已经变了。我踩坑时的表现就是连续粘贴两次第二次内容老是插到第一个字符后面。正确的顺序是点击粘贴按钮 → 同步获取 offset → 异步读取剪贴板 → 异步插入 → 异步设置 offset。哪怕读取耗时 500ms只要 offset 是在点击瞬间锁定的插入位置就不会偏。3.5 代码段五监听剪贴板更新并做节流最后一段代码是给 UI 提供剪贴板是否有可粘贴内容的能力同时避开监听回调和读取回调的竞争问题。import { pasteboard } from kit.BasicServicesKit; export class ClipboardWatcher { private sysPasteboard pasteboard.getSystemPasteboard(); private timer: number | undefined; private version 0; // 简化的回调把最新内容状态抛给 UI onChange: ((available: boolean) void) | undefined; start(): void { this.sysPasteboard.on(update, () { // 每来一次 update版本号加一 const current this.version; // 节流避免高频复制时反复触发 getData // 实际项目建议用 setTimeout 或 debounce if (this.timer) { clearTimeout(this.timer); } this.timer setTimeout(async () { // 只有版本号依然是最新的那次回调才有权刷新 UI if (current ! this.version) { return; } const content await readClipboardContent(); const available !!(content.html || content.text || (content.uriList content.uriList.length 0)); this.onChange?.(available); }, 120); }); } stop(): void { this.sysPasteboard.off(update); if (this.timer) { clearTimeout(this.timer); } this.version 0; } }版本号加节流的组合是我在这个坑里摸索出来的关键。版本号保证过期回调不生效节流保证高频复制时不会疯狂getData()导致性能问题。4. 实测观察不同 API 版本和不同真机的粘贴差异代码写完只是第一步这个功能真正麻烦的是兼容性。我把手头能拿到的设备和模拟器都跑了一遍记录了一些值得注意的差异。4.1 API 9 到 API 12 的关键变化系统版本主要表现注意点API 9getPrimaryHtml偶尔拿不到遍历 record 更可靠建议做兜底读取API 10系统设置里新增剪贴板权限提示多任务切换时剪贴板可能被系统清理setData 后立即读取没问题但不要依赖长时间存活API 11部分设备上on(update)出现系统应用触发的高频回调必须加节流API 12RichEditor 相关接口更完整自定义粘贴插入更方便可以逐步迁移到 controller 方案模拟器和真机之间也有差异。模拟器上剪贴板数据读取延迟普遍比真机更低时序竞争问题不容易复现。真机尤其是配置较低的机型getData()延时会明显增加粘贴按钮连点场景很容易触发坑二里的光标错位问题。所以我的建议是这类功能一定要在至少一台低端真机上压测不要只信模拟器。4.2 长文本、图片、链接混合内容的实测结果我压测了三组内容纯文本 10 万字符从网页复制后粘贴到编辑器耗时约 120ms无明显卡顿。富文本包含表格、多级标题、内联样式粘贴后清洗耗时最明显的是正则处理阶段对超大 HTML 建议把清洗放到子线程。图片复制MIME_TEXT_URI在编辑器里如果只是插入uri图片可能无法直接显示需要先做权限校验和路径转换。我自己项目里的实际体验是整个粘贴流程的耗时分布大概是读取剪贴板占了 50%HTML 清洗占了 30%插入渲染占了 20%。如果发现粘贴后 UI 卡顿优先检查清洗函数是不是在主线程跑了超大字符串。5. 工程落地的最后一点建议最后分享几条代码之外的工程经验。复制粘贴保真攻坚表面上只是剪贴板读写实际上更像一次链路治理。我从这个需求里提炼出的核心结论是所有复制入口必须统一收口到一个写入方法而不是散落在各个业务页面里各自调用setData()。只要有一个入口绕过统一方法富文本保真就会功亏一篑。项目里最好做一个 lint 规则或者上层封装强制业务侧只能走writeClipboardWithHtml。粘贴侧也一样不要在业务代码里到处getData()。把读取逻辑收敛到readClipboardContent再往上层提供语义化接口这样后续做权限、埋点、数据统计都会轻松很多。另外如果你们的测试体系允许强烈建议加一个自动化用例在 WebView 里构造一段带样式的 HTML触发复制然后切入到编辑器页粘贴断言粘贴后的 HTML 结构里是否保留了color和font-weight。这个用例能防止坑一以某个低优先级接口又覆盖了剪贴板的形式悄悄回归。我在这次攻坚里另一个比较大的收获是与其追求一个绝对完美的全类型保真不如先把 90% 高频场景的链路做扎实文本、基础富文本、图片这三种数据形态覆盖了绝大多数用户诉求。做产品也是一样的道理先把主干跑通再去抠边界比一开始就想着穷尽所有剪贴板场景要务实得多。
前阵子排查一个鸿蒙应用里的粘贴问题用户反馈说在网页里明明选了一段带颜色、带加粗的标题复制到编辑器里颜色没了加粗也没了标题直接变成一行裸文本。最要命的是粘贴位置还偶尔不对明明光标在段尾结果内容插到了段首。这类问题就是典型的剪贴板保真问题。我做了两件事先把鸿蒙系统剪贴板这一层彻底捋了一遍再把编辑器侧的粘贴链路重新设计了一遍。这篇文章就是这次攻坚的完整记录重点写三个我实际踩到的坑以及最终沉淀下来的五段核心代码。希望给正在做鸿蒙富文本编辑器、笔记类 App、或者有自定义粘贴需求的同学一些参考。1. 鸿蒙剪贴板的数据模型以及保真到底保的是什么先说结论鸿蒙的系统剪贴板并不是一个简单的字符串缓冲区它内部是一套 PasteData 结构。一个 PasteData 下面可以挂多个 PasteDataRecord每条 record 都有独立的 MIME 类型。这意味着剪贴板在同一时间可以同时保存一份 HTML、一份纯文本、甚至一组 Uri 或 Want 数据。系统剪贴板 └── PasteData ├── Record 1: MIME_TEXT_HTML, p style\color:red\标题/p ├── Record 2: MIME_TEXT_PLAIN, 标题 └── Record 3: MIME_TEXT_URI, [file://... ]所以保真这个概念落到代码层面其实就是用户在源端复制时你是否把完整的数据类型写进了 PasteData你在目标端粘贴时是否按正确的优先级读回了数据并且在编辑器光标位置原样插入。1.1 PasteData 与 MIMETYPE剪贴板其实是一个小容器很多初学者容易把剪贴板理解成一个setText(getText())的简陋接口能贴能拿就行。但一旦做富文本编辑器这种理解会立刻翻车。鸿蒙的ohos.pasteboard模块中常用 MIME 类型有MIME 类型常量说明text/plainpasteboard.MIMETYPE_TEXT_PLAIN纯文本text/htmlpasteboard.MIMETYPE_TEXT_HTML富文本 HTMLtext/uri-listpasteboard.MIMETYPE_TEXT_URIUri 列表常用于图片/文件application/happasteboard.MIMETYPE_HAP应用包类型编辑器场景一般不用从网页、文档、或者系统级组件复制出来的内容大多数情况下会同时包含 HTML 和纯文本两条记录。HTML 是给富文本编辑器用的纯文本是给文本框、搜索框这类只能接收纯文本的场景用的。而保真攻坚的重点就是确保 HTML 这条管道不被截断。1.2 编辑器侧复制粘贴的三种入口鸿蒙应用里的粘贴操作并不是只有一种触发方式我实际调研下来编辑器场景通常有三个入口系统级上下文菜单触发的粘贴点击后由系统完成数据读取和文本写入。应用内自定义的粘贴按钮通过监听剪贴板数据后调用编辑器接口写入。WebView 内通过 JSBridge 调用原生去读写剪贴板。这三种入口的代码路径不同数据表现也不一样。系统级菜单粘贴往往不会给你任何拦截机会编辑器拿到的已经是系统处理过的内容自定义按钮则是你自己控制读写保真可控性最强WebView 方案则要看壳的封装是否把 MIME 类型都传给了原生层。所以做保真攻坚时第一步不是写代码而是确认你的编辑器走的是哪条粘贴路径。2. 三个坑格式降级、光标丢失、监听竞争2.1 坑一HTML 与纯文本没有成对写入富文本静默降级这个坑是我排查用户反馈时发现的第一现场。用户复制的是一条网页标题我用系统剪贴板工具看过里面明明有p标签、有 style 样式。但进入编辑器后读取到的只有纯文本HTML 记录凭空消失。我花了大半天时间最后排查出来的原因很无语项目的复制入口不止一个。部分列表项的长按菜单里有一段旧代码直接调用的是pasteboard.createData(pasteboard.MIMETYPE_TEXT_PLAIN, item.title)然后再setData()。这段代码执行时会用一份只有纯文本的 PasteData 整体覆盖掉系统剪贴板。也就是说用户复制到一半时还是完整的富文本但某个松散的联动逻辑又写了一次纯文本记录把之前的 HTML 记录顶掉了。这个问题的关键是setData()不是追加而是整体替换。只要有一次地方用单类型数据调用setData()剪贴板里所有类型的旧记录全部丢失。2.2 坑二粘贴位置光标偏移插入点永远是错的第二个坑出现在自定义粘贴按钮的路径里。我最初的实现思路是粘贴按钮被点击后先异步去getData()拿到 HTML 之后再插入到编辑器的光标位置。看起来没毛病但实际测试时频繁出现内容插到错误位置的情况。原因在于读剪贴板是异步操作耗时通常在几十到几百毫秒。用户点击粘贴按钮后如果编辑区焦点还在光标位置理论上不变但如果在此之前用户又点了一下编辑区或者输入法弹窗刚好调整了布局光标的 offset 已经不是原来的值了。更常见的是某些自定义编辑器在getData()回调返回之前已经把选区清空了我在回调里读到的caretOffset是 -1最后默认插入到了开头。后来我把方案改成了先锁光标再读数据最后插入才基本稳定。锁光标的方式不复杂关键在于时机必须在用户触发粘贴动作的同步阶段立刻记录光标位置不能等异步回调回来再取。2.3 坑三剪贴板 update 监听与异步读取的时序竞争第三个坑和 UI 状态有关。我希望工具栏的粘贴按钮能实时感知系统剪贴板是否有内容于是用了pasteboard.getSystemPasteboard().on(update, ...)监听剪贴板变化。初版代码在回调里直接getData()然后刷新按钮。实际运行一段时间后偶尔出现按钮状态和剪贴板内容对不上有时复制了新内容按钮始终置灰有时剪贴板已经没内容了按钮却一直高亮。我梳理时序后发现问题出在多个应用/模块同时写入剪贴板时的监听频率很高系统回调是异步的某些场景下getData()还在飞行途中另一次update又触发了旧回调携带的结果反而覆盖了新状态。也就是说回调本身没有串行保证我不能依赖最后一次回调为最终状态。正确做法是给数据读取加版本号或者做节流并且把update监听只当作提示不当作权威数据源。真正要获取内容时通过显式的读取动作去拿而不是依赖监听回调里的返回值。3. 五段代码从系统剪贴板到编辑器光标的完整管线下面这五段代码是我在项目里最终沉淀下来的核心实现。整条管线按照写入 → 读取 → 清洗 → 插入 → 监听五个环节拆分每段都能单独复用。3.1 代码段一成对写入 HTML 与纯文本不管你的复制源是网页、文档、还是系统组件只要内容可能带格式都必须同时写入 HTML 和纯文本两条记录。否则粘贴到纯文本输入框时用户看到的可能是一堆标签。import { pasteboard } from kit.BasicServicesKit; export async function writeClipboardWithHtml(html: string, plainText: string): Promisevoid { // 1. 用 HTML 作为主记录创建 PasteData const pasteData pasteboard.createData(pasteboard.MIMETYPE_TEXT_HTML, html); // 2. 追加一条纯文本 record确保纯文本场景也能正常粘贴 pasteData.addRecord(pasteboard.createRecord(pasteboard.MIMETYPE_TEXT_PLAIN, plainText)); // 3. 部分 API 版本支持设置 property声明本条 pasteData 包含的类型 // 旧版本不支持时用 try/catch 兜底不要影响主流程 try { const property new pasteboard.PasteDataProperty(); property.addMimeType(pasteboard.MIMETYPE_TEXT_HTML); property.addMimeType(pasteboard.MIMETYPE_TEXT_PLAIN); pasteData.setProperty(property); } catch (error) { console.warn(set property skipped, error:, error); } // 4. 整体写入系统剪贴板 const sysPasteboard pasteboard.getSystemPasteboard(); await sysPasteboard.setData(pasteData); }这里有一个细节createData()之后addRecord()是追加操作而不是新建覆盖。所以如果复制源本身就是 WebView建议把网页提取出来的 HTML 和document.body.innerText成对传入这个方法。纯文本不干净时宁可多清理一次也不要丢掉 HTML。3.2 代码段二按优先级读取HTML 优先纯文本兜底读取侧的核心原则是优先拿 HTML拿不到再退回纯文本。不要反着来否则富文本能力会被白白浪费。import { pasteboard } from kit.BasicServicesKit; export interface ClipboardContent { html?: string; text?: string; uriList?: string[]; } export async function readClipboardContent(): PromiseClipboardContent { const result: ClipboardContent {}; const sysPasteboard pasteboard.getSystemPasteboard(); try { const data await sysPasteboard.getData(); // 1. 优先尝试从主记录里直接取 Html 和 PlainText if (data.hasType(pasteboard.MIMETYPE_TEXT_HTML)) { const html data.getPrimaryHtml(); if (html) { result.html html; } } if (data.hasType(pasteboard.MIMETYPE_TEXT_PLAIN)) { const text data.getPrimaryText(); if (text) { result.text text; } } // 2. 如果主记录没有再遍历所有 record 逐一查找 if (!result.html || !result.text) { const records data.getRecords(); for (let i 0; i records.length; i) { const record records[i]; if (!result.html record.mimeType pasteboard.MIMETYPE_TEXT_HTML) { result.html record.html; } if (!result.text record.mimeType pasteboard.MIMETYPE_TEXT_PLAIN) { result.text record.plainText; } } } // 3. 处理图片/文件粘贴场景 if (data.hasType(pasteboard.MIMETYPE_TEXT_URI)) { result.uriList []; const records data.getRecords(); for (let i 0; i records.length; i) { const uri records[i].uri; if (uri) { result.uriList.push(uri); } } } } catch (error) { console.error(read pasteboard failed:, error); } return result; }hasType和getPrimaryHtml这些接口在部分 API 版本里返回值可能为空所以我加了主记录拿不到就遍历 record的兜底逻辑。实测下来不同的系统版本表现不完全一样有的版本主记录就够有的必须遍历才能拿到全部数据。3.3 代码段三把 HTML 清洗成编辑器内部结构带样式白名单直接从网页复制来的 HTML 通常充斥着大量无用标签、内联样式、甚至脚本。不能原样插进编辑器一方面排版会乱另一方面有安全风险。所以我在插入之前先做一次清洗。const STYLE_WHITELIST new Set([ color, background-color, font-weight, font-style, text-decoration, text-align, ]); const TAG_BLACKLIST new Set([ script, style, iframe, object, embed, ]); export function sanitizeHtml(rawHtml: string): string { if (!rawHtml) { return ; } // 1. 去掉黑名单标签及内容 let html rawHtml.replace(/script[\s\S]*?\/script/gi, ); html html.replace(/style[\s\S]*?\/style/gi, ); html html.replace(/iframe[\s\S]*?\/iframe/gi, ); html html.replace(/object[\s\S]*?\/object/gi, ); html html.replace(/embed[\s\S]*?\/embed/gi, ); // 2. 清洗每个开始标签的内联样式 html html.replace(/([a-zA-Z][a-zA-Z0-9]*)([^]*)/g, ( fullTag: string, tagName: string, attrs: string, ) { const tag tagName.toLowerCase(); // 非白名单标签一律还原成无属性标签 if (TAG_BLACKLIST.has(tag)) { return ${tagName}; } // 提取 style 属性里的声明 const styleMatch attrs.match(/style\s*\s*([^]*)/i); if (!styleMatch) { return ${tagName}; } const keptStyles styleMatch[1] .split(;) .map((item) item.trim()) .filter((item) { const prop item.split(:)[0]?.trim().toLowerCase(); return prop STYLE_WHITELIST.has(prop); }) .join(;); return keptStyles ? ${tagName} style${keptStyles} : ${tagName}; }); return html; }这段清洗逻辑并不是一个完整的 HTML parser对于生产环境我更推荐在 WebView 侧用 DOM API 去遍历节点。但在 Native 编辑器里需要一个轻量兜底时这个白名单方案足够解决 90% 的样式污染问题。3.4 代码段四在光标位置插入并维护选区清洗完 HTML 之后终于可以插入了。这一步的要点是锁光标、再插入、最后恢复选区。export interface EditorInsertContent { html: string; text: string; } export interface EditorLike { getCaretOffset(): number; setCaretOffset(offset: number): void; insertHtmlAt(offset: number, html: string, text: string): void; getSelection(): { start: number; end: number }; } export function insertContentAtCaret( editor: EditorLike, content: EditorInsertContent, ): void { // 1. 在用户触发粘贴的同步阶段记录光标位置 const caretOffset editor.getCaretOffset(); // 如果拿不到光标放弃自动插入让系统默认流程走 if (caretOffset 0) { return; } // 2. 在这里插入内容。真实项目如果基于 RichEditor // API 12 起可直接用 controller.insertText 之类接口 // 如果基于 WebView则是通过 evaluateJavaScript 插入并返回 offset。 editor.insertHtmlAt(caretOffset, content.html, content.text); // 3. 插入完成后把光标移动到内容末尾 const insertedLength content.text.length; const nextOffset caretOffset insertedLength; editor.setCaretOffset(nextOffset); }为什么要强调同步阶段记录光标位置因为剪贴板读取和插入是两个异步步骤。如果你的代码在await readClipboardContent()之后才取 offset这中间用户可能已经在编辑区产生了新的点击offset 已经变了。我踩坑时的表现就是连续粘贴两次第二次内容老是插到第一个字符后面。正确的顺序是点击粘贴按钮 → 同步获取 offset → 异步读取剪贴板 → 异步插入 → 异步设置 offset。哪怕读取耗时 500ms只要 offset 是在点击瞬间锁定的插入位置就不会偏。3.5 代码段五监听剪贴板更新并做节流最后一段代码是给 UI 提供剪贴板是否有可粘贴内容的能力同时避开监听回调和读取回调的竞争问题。import { pasteboard } from kit.BasicServicesKit; export class ClipboardWatcher { private sysPasteboard pasteboard.getSystemPasteboard(); private timer: number | undefined; private version 0; // 简化的回调把最新内容状态抛给 UI onChange: ((available: boolean) void) | undefined; start(): void { this.sysPasteboard.on(update, () { // 每来一次 update版本号加一 const current this.version; // 节流避免高频复制时反复触发 getData // 实际项目建议用 setTimeout 或 debounce if (this.timer) { clearTimeout(this.timer); } this.timer setTimeout(async () { // 只有版本号依然是最新的那次回调才有权刷新 UI if (current ! this.version) { return; } const content await readClipboardContent(); const available !!(content.html || content.text || (content.uriList content.uriList.length 0)); this.onChange?.(available); }, 120); }); } stop(): void { this.sysPasteboard.off(update); if (this.timer) { clearTimeout(this.timer); } this.version 0; } }版本号加节流的组合是我在这个坑里摸索出来的关键。版本号保证过期回调不生效节流保证高频复制时不会疯狂getData()导致性能问题。4. 实测观察不同 API 版本和不同真机的粘贴差异代码写完只是第一步这个功能真正麻烦的是兼容性。我把手头能拿到的设备和模拟器都跑了一遍记录了一些值得注意的差异。4.1 API 9 到 API 12 的关键变化系统版本主要表现注意点API 9getPrimaryHtml偶尔拿不到遍历 record 更可靠建议做兜底读取API 10系统设置里新增剪贴板权限提示多任务切换时剪贴板可能被系统清理setData 后立即读取没问题但不要依赖长时间存活API 11部分设备上on(update)出现系统应用触发的高频回调必须加节流API 12RichEditor 相关接口更完整自定义粘贴插入更方便可以逐步迁移到 controller 方案模拟器和真机之间也有差异。模拟器上剪贴板数据读取延迟普遍比真机更低时序竞争问题不容易复现。真机尤其是配置较低的机型getData()延时会明显增加粘贴按钮连点场景很容易触发坑二里的光标错位问题。所以我的建议是这类功能一定要在至少一台低端真机上压测不要只信模拟器。4.2 长文本、图片、链接混合内容的实测结果我压测了三组内容纯文本 10 万字符从网页复制后粘贴到编辑器耗时约 120ms无明显卡顿。富文本包含表格、多级标题、内联样式粘贴后清洗耗时最明显的是正则处理阶段对超大 HTML 建议把清洗放到子线程。图片复制MIME_TEXT_URI在编辑器里如果只是插入uri图片可能无法直接显示需要先做权限校验和路径转换。我自己项目里的实际体验是整个粘贴流程的耗时分布大概是读取剪贴板占了 50%HTML 清洗占了 30%插入渲染占了 20%。如果发现粘贴后 UI 卡顿优先检查清洗函数是不是在主线程跑了超大字符串。5. 工程落地的最后一点建议最后分享几条代码之外的工程经验。复制粘贴保真攻坚表面上只是剪贴板读写实际上更像一次链路治理。我从这个需求里提炼出的核心结论是所有复制入口必须统一收口到一个写入方法而不是散落在各个业务页面里各自调用setData()。只要有一个入口绕过统一方法富文本保真就会功亏一篑。项目里最好做一个 lint 规则或者上层封装强制业务侧只能走writeClipboardWithHtml。粘贴侧也一样不要在业务代码里到处getData()。把读取逻辑收敛到readClipboardContent再往上层提供语义化接口这样后续做权限、埋点、数据统计都会轻松很多。另外如果你们的测试体系允许强烈建议加一个自动化用例在 WebView 里构造一段带样式的 HTML触发复制然后切入到编辑器页粘贴断言粘贴后的 HTML 结构里是否保留了color和font-weight。这个用例能防止坑一以某个低优先级接口又覆盖了剪贴板的形式悄悄回归。我在这次攻坚里另一个比较大的收获是与其追求一个绝对完美的全类型保真不如先把 90% 高频场景的链路做扎实文本、基础富文本、图片这三种数据形态覆盖了绝大多数用户诉求。做产品也是一样的道理先把主干跑通再去抠边界比一开始就想着穷尽所有剪贴板场景要务实得多。
