app端uni.setclipboarddata静默失败主因是manifest未启用剪贴板模块：ios需勾选「剪贴板」并重新云打包，android需启用clipboard模块；厂商系统后台会拦截读取，须用户点击后立即调用并加超时兜底；h5端该api为空实现，须用navigator.clipboard或降级方案。
App端uni.setClipboardData静默失败，大概率是manifest没开剪贴板模块
iOS 和 Android 均需在 manifest.json 中显式启用剪贴板能力，否则调用会走低效兼容路径或直接阻塞——不报错、不弹窗、也不进 success/fail 回调，看着就像“被占用了”。
- iOS：打开
manifest.json→「App 设置」→「iOS 设置」→ 勾选「剪贴板」，**必须重新云打包**才生效 - Android：同文件 →「模块权限配置」→ 启用「clipboard」模块（对应原生
READ_CLIPBOARD和WRITE_CLIPBOARD） - 检查编译后产物：
ios/Podfile应含pod 'UniClipboard'；android/app/src/main/AndroidManifest.xml应有对应 permission 声明
厂商系统（华为/小米）后台拦截剪贴板，导致getClipboardData卡在 pending
Android 厂商定制系统会在 App 退到后台、失去焦点或处于省电模式时，静默拒绝剪贴板读取请求。现象是 uni.getClipboardData 既不进 success 也不进 fail，Promise 一直挂起。
- 无法通过代码绕过，这是系统级限制
- 规避方式：只在用户点击后立即调用，避免在
onShow或定时器里读取 - 加超时兜底：
Promise.race([uni.getClipboardData(), new Promise((_, r) => setTimeout(() => r(new Error('timeout')), 1500))]) - 提示用户：“请保持页面在前台，并点击按钮重试”
写入后立刻被其他App覆盖，不是“被占用”，而是系统共享机制
剪贴板是操作系统全局区域，uni-app 没有任何 API 能监听、拦截或清空他人写入的内容。所谓“刚复制完就被覆盖”，其实是微信、钉钉、浏览器等 App 在你调用之后又执行了写入操作。
- 别试图轮询 + 自动覆盖——这既无效，还可能引发用户反感
- 真正可控的是你的读取逻辑：每次
uni.getClipboardData后，先做.replace(/[\u200b-\u200f\u202a-\u202f\uFEFF]/g, '')清零宽字符，再.trim() - 若业务强依赖口令识别，建议正则提取关键字段（如
code=([A-Z2-9]{8})），而非全量匹配
H5端误用uni.setClipboardData，表现像“复制失败”
如果当前平台是 H5，uni.setClipboardData 是空实现，调用后无反应、无报错、也不进回调——容易误判为“被占用”或“卡死”。
- 必须提前判断：
if (uni.getSystemInfoSync().platform === 'h5') - H5 只能用
navigator.clipboard.writeText(text)（HTTPS + 用户点击同步上下文） - 降级 fallback 必须包含临时
<textarea></textarea>+select()+document.execCommand('copy')，否则老安卓 WebView 会失败 - 注意：H5 下
uni.getClipboardData同样不可用，读取必须靠用户手动粘贴 +@paste事件捕获
