uni.setClipboardData仅支持纯字符串，传HTML、对象或null会静默失败；H5端需用navigator.clipboard.writeText配合text/html类型（限HTTPS及iOS Safari 16.4+），其他平台均降级为纯文本。
uni.setClipboardData 只接受纯字符串，别传 HTML 或对象
uni-app 的 uni.setClipboardData 本质是调用各端原生剪贴板 API 的封装，而所有平台（iOS/Android/小程序/H5）的底层写入接口都只支持纯文本格式。传 JSON、HTML 字符串甚至带换行的富文本，剪贴板里存的仍是字面量字符串——粘贴到微信、备忘录或短信里，不会自动渲染成加粗或列表，只会原样显示标签或乱码。
- 传
{"name":"张三"}→ 粘贴出来就是这串字符，不是对象 - 传
<h1>标题</h1><p>正文</p>→ 粘贴后显示为“<h1>标题</h1><p>正文</p>”，不是带样式的标题 - 传
null、{}、123→ 静默失败，剪贴板内容不变，控制台无报错
必须在调用前做类型归一化：String(content) 或 JSON.stringify(obj)，再 .trim() 去首尾空格。
H5 端想粘贴带格式？只能用 navigator.clipboard.write + text/html
H5 是唯一可能保留简单格式的出口，但限制极严：仅 HTTPS 或 localhost 环境可用，且必须用户点击同步触发；iOS Safari 16.4+ 才支持 text/html 类型，旧版仍 fallback 到纯文本。
- 不能用
uni.setClipboardData—— 它在 H5 是空壳，调用即失效 - 正确写法是构造
ClipboardItem：new ClipboardItem({ 'text/html': new Blob([htmlStr], { type: 'text/html' }) }) - 目标应用是否识别该格式，取决于它自身逻辑（如微信 PC 版可识别，手机微信仍大概率降级为纯文本）
App 和小程序端完全不支持 text/html，强行写入会被忽略，最终还是纯文本。
多行文本换行符怎么处理才不被 iOS 吞掉
iOS 对连续换行特别敏感：粘贴时若开头/结尾有空行，或中间出现 ≥3 个连续 \n，备忘录和微信会自动合并或裁掉。这不是 bug，是系统级解析策略。
- 用正则统一归一化：
text.replace(/\n{3,}/g, '\n\n').replace(/^[\r\n\s\u200B]+|[\r\n\s\u200B]+$/g, '') - 开头结尾加零宽空格
\u200B防裁剪（尤其当内容以换行开头时） - 避免用
innerText直接取 DOM 内容——它可能把<br>
转成\n，也可能漏掉语义换行
真正起作用的不是“用了什么换行符”，而是最终字符串里 \n 的数量和位置是否落在目标应用的容忍区间内。
从富文本组件取内容时，怎么降级又不失关键语义
如果你的文本来自 <editor> 或自定义富文本组件，直接取 innerHTML 或服务端返回的 HTML，必须清洗，但清洗不是简单删标签。
- 用
textContent或正则/<[^>]*>/g剥离标签，保留原始换行 - 把
<h1>→ 替换为【标题】\n，<ul><li>→ 替换为•，避免信息断层 - 别传
JSON.stringify(htmlObj)—— 对方粘贴后看到的是字符串，不是结构化数据
最易被忽略的一点：清洗后务必 .trim()，否则首尾不可见字符（如 \u200B、\u00A0）会导致某些 App 解析失败或静默丢内容。
