uni.copyToClipboard 写入超大文本（>100KB）时 App 端卡顿甚至假死，是因 iOS UIPasteboard 和 Android ClipboardManager 均为同步阻塞操作，无分块或异步封装，导致主线程长时间 hang 住。
uni.copyToClipboard 写入超大文本（如 >100KB）时，App 端会明显卡顿甚至假死，这不是 bug，是原生剪贴板 API 的同步阻塞行为 —— 尤其在 iOS 上，UIPasteboard 对大字符串写入无异步支持，主线程直接 hang 住。
为什么大文本会让 App 卡住
uni-app 的 uni.copyToClipboard 在 App 端最终调用的是原生剪贴板接口：iOS 走 UIPasteboard，Android 走 ClipboardManager。两者对大文本（比如日志 dump、JSON 字符串、Base64 图片）均无分块或异步封装，底层是同步内存拷贝 + 序列化操作。实测 iOS 上写入 500KB 文本，主线程阻塞常达 800ms–2s；Android 部分低端机型更甚，还可能触发 ANR。
- 不是权限问题（权限缺失只会静默失败或走降级路径）
- 不是 JS 层逻辑慢，V8 引擎执行
uni.copyToClipboard前几乎不耗时 - 真机卡顿、模拟器不卡 → 典型原生层阻塞特征
必须做内容截断或分块处理
别指望“等它自己优化”，必须在调用前主动控制文本体积。剪贴板本质是系统级共享缓存，不是存储介质 —— 用户极少需要复制 MB 级内容，强行支持反而损害体验。
- 前端强校验：复制前用
text.length * 2（UTF-16 字节估算）判断是否超限，建议阈值设为64 * 1024（64KB） - 超限时自动截断并提示：“内容过长，已复制前 64KB”
- 若业务真需完整内容（如导出日志），改用文件下载：
uni.downloadFile+uni.saveFile，再通过uni.openDocument打开 - 禁止把
JSON.stringify(largeData)直接丢给uni.copyToClipboard，先JSON.stringify(largeData, null, 2)格式化再截断，避免无意义空格拖累体积
避免在 UI 线程中直接调用
即使内容合规，也不该在用户点击后立刻同步执行 uni.copyToClipboard。iOS WebView 容易因主线程繁忙导致 touch 响应延迟，视觉上就是“点下去没反应”。
- 加一层
setTimeout(() => uni.copyToClipboard(text), 0)把调用推到下一个宏任务，释放当前渲染帧 - 更稳妥的做法：显示“复制中…” loading 状态，再 setTimeout 调用，完成后恢复按钮状态
- 不要用
await uni.copyToClipboard()包裹大文本操作 —— 它不会变快，只是让 JS 等得更明显 - Android 端可额外加
plus.runtime.getProperty('platform') === 'android'判断，对超 32KB 内容强制用plus.clipboard.set({content: text})（需启用 plus 模块），它比 uni 封装略快一点
H5 和小程序端不受此影响，但有各自限制
这个问题纯属 App 端原生层缺陷，H5 用 navigator.clipboard.writeText 是异步 Promise，小程序用 wx.setClipboardData 也是异步回调，都不会卡 UI。但要注意：
- H5 端：若文本含特殊字符（如 \u200B 零宽空格），
navigator.clipboard.writeText可能拒绝写入，需提前text.replace(/\u200B/g, '') - 小程序端：仍受“用户手势触发”约束，不能脱离 click/tap 链路，否则静默失败
- 三端统一处理建议：封装一个
safeCopy(text)函数，内部按平台分流 + 体积检查 + 截断逻辑，业务层只管调用
真正难的不是写截断逻辑，而是说服产品接受“剪贴板不该存大文本”这个事实 —— 大多数所谓“需要复制全部”的场景，其实只是缺乏更好的导出路径。与其硬扛原生限制，不如把 uni.downloadFile + uni.openDocument 做成标准导出按钮。
