uni.copyToClipboard在App端慢因权限未启用，iOS需勾选manifest中“剪贴板”，Android需启用“clipboard”模块；小程序须用户手势直接触发；H5应优先用navigator.clipboard.writeText并做好降级处理。
uni.copyToClipboard 在 App 端写入慢？先查 manifest 权限配置
App 端（iOS/Android）调用 uni.copyToClipboard 明显卡顿，大概率不是代码问题，而是原生能力没启用——它不会报错，但会走降级路径或同步阻塞等待，导致延迟 300ms 甚至秒级。iOS 和 Android 都必须显式开启对应模块，否则底层 fallback 到低效的兼容逻辑。
- iOS：manifest.json →「App 设置」→「iOS 设置」→ 勾选「剪贴板」权限（不勾选时，系统用 UIPasteboard 的旧 API，无异步支持）
- Android：manifest.json →「模块权限配置」→ 启用「clipboard」模块（对应原生
android.permission.READ_CLIPBOARD和WRITE_CLIPBOARD，缺一不可） - 检查编译后生成的
ios/Podfile或android/app/src/main/AndroidManifest.xml，确认是否已注入 clipboard 相关依赖（HBuilderX 3.9+ 自动生成，旧版本需手动补）
微信小程序里 copyToClipboard 被卡住？别跨宏任务触发
小程序端 uni.copyToClipboard 实际调用的是 wx.setClipboardData，而微信强制要求“用户手势直接触发”，一旦脱离 click/tap 的同步调用链，就会进入 pending 状态或静默失败——这不是 bug，是平台策略。
- ❌ 错误写法：
setTimeout(() => uni.copyToClipboard(...), 0)、this.$nextTick(() => ...)、Promise.then(() => ...) - ✅ 正确写法：事件处理器第一层就 await，例如
@click="handleCopy"，且handleCopy内直接调用await uni.copyToClipboard(...) - 若内容需异步获取（如接口返回后复制），确保请求发起和复制调用都在同一用户手势上下文中，且中间不要插入
await以外的异步分隔（比如不能await api(); await nextTick(); await uni.copyToClipboard()）
H5 端写入延迟高？优先用 navigator.clipboard.writeText + 条件检测
H5 用 uni.copyToClipboard 是无效的（静默失败），必须走浏览器原生 API。但 navigator.clipboard.writeText 在部分安卓 WebView 或旧版 Safari 中会 fallback 到 document.execCommand，而后者涉及 DOM 操作和 focus 处理，极易引入 100–400ms 延迟。
- 先做双保险检测：
if (navigator.clipboard && window.isSecureContext)，避免 HTTPS 缺失时抛NotAllowedError - 降级到
document.execCommand时，必须创建临时<textarea></textarea>并执行完整流程：textarea.select()→textarea.setSelectionRange(0, text.length)→document.execCommand('copy')，漏掉setSelectionRange在 iOS Safari 会失败 - 避免在滚动、动画帧中触发复制；可加节流（如 500ms 内只允许一次），防止连续点击堆积 DOM 操作
跨端统一封装时，为什么 copy 函数仍慢？检查平台编译与 Promise 链
即使你写了条件编译的跨端 copy 函数，实际运行仍慢，往往因为编译残留或 Promise 处理不当——uni-app 的条件编译（#ifdef）不是运行时判断，而是构建时剔除，若写法有误，H5 端可能偷偷执行了 App 端逻辑。
- 确认 H5 端实际运行的是
navigator.clipboard.writeText而非uni.copyToClipboard：在 H5 控制台打印typeof uni.copyToClipboard，应为"undefined" - 所有跨端 copy 调用必须返回 Promise 并 await，不要用
then后续再做耗时操作（如弹 toast），否则会拉长感知延迟；toast 应在 Promise resolve 后立即调用，不要等下一轮事件循环 - 避免在 copy 函数内做字符串拼接、JSON.stringify 等 CPU 密集操作——尤其当
text是大对象时，先String(text)或提前序列化，别在 Promise 回调里现场处理
