iOS真机首次调用uni.getClipboardData必弹系统授权窗；若无弹窗且success/fail均不触发，说明用户已拒绝权限并被静默拦截，此时应提示用户手动开启剪贴板权限。
uni.getClipboardData 调用后没弹窗也不返回结果，说明用户已拒绝
iOS 真机上，uni.getClipboardData 首次调用一定会触发系统级授权弹窗；如果既没弹窗、success 也不进、fail 也没回调，基本可以断定用户之前点过「不允许」，且系统记住了这个选择。这不是 API 失败，而是被静默拦截——连错误信息都不抛，控制台也无日志。
此时你无法通过代码再次唤起弹窗，微信小程序同理（首次拒绝后，uni.getClipboardData 直接走 fail 回调，errMsg 为 "getClipboardData:fail auth deny"）。
- 别尝试重试或 setTimeout 延迟调用，无效
- 不要在
onShow或页面初始化时自动读取，这会加剧“静默失败”现象 - 可加一层轻量提示：
uni.showToast({ title: '请手动开启剪贴板权限', icon: 'none' })，再引导用户去「设置 → 隐私与安全性 → 剪贴板」打开开关
微信小程序能用 getSetting 检查权限状态
微信平台提供了 uni.getSetting，可同步获取当前权限状态。它不适用于 iOS App 或 H5，但在小程序里是唯一可靠的判断方式：
uni.getSetting({
success: (res) => {
if (res.authSetting['scope.writeClipboard'] === false) {
// 用户明确拒绝过
console.log('用户已拒绝剪贴板权限')
} else if (res.authSetting['scope.writeClipboard'] === undefined) {
// 未授权，下次调用会弹窗
console.log('尚未授权，首次调用将弹窗')
}
}
})
- 注意字段名是
scope.writeClipboard（不是scope.userclipboardwrite），这是微信文档中实际生效的 key - 必须在用户点击等合法上下文中调用
uni.getSetting，否则可能返回空对象 - 该接口不能用于 Android/iOS App 端，manifest.json 里没对应机制
iOS App 和 H5 根本没有“检查权限状态”的 API
iOS 原生层不暴露剪贴板权限的查询接口，uni.getSystemInfoSync().platform === 'ios' 后，你只能靠行为反推：调用 uni.getClipboardData 后若 success 和 fail 都不触发，大概率已被拒绝；H5 更彻底——navigator.clipboard.readText() 在未授权时直接抛 NotAllowedError，但你无法提前知道是否已授过权。
- H5 端不要试图用
navigator.permissions.query({ name: 'clipboard-read' })，iOS Safari 和多数安卓 WebView 不支持该 API - App 端即使调用原生模块，也无法绕过系统限制拿到“是否允许读取”的布尔值
- 所有平台都不存在“主动申请并等待用户点确定后再继续”的流程，授权弹窗和 API 调用是一体的
真正能落地的判断逻辑只有“响应式兜底”
与其纠结“怎么提前知道”，不如接受现实：你只能在调用后根据响应决定下一步。关键不是预测，而是处理好三种情况：
-
成功返回非空字符串：清洗内容（
String(res.data || '').replace(/[\u200b-\u200f\u202a-\u202f]/g, '').trim()），再做业务匹配 -
进入
fail回调且errMsg含"auth deny"：明确提示用户去系统设置开启，并禁用相关按钮 - 既不 success 也不 fail（尤其 iOS）：视为已拒绝，展示引导文案，避免无限轮询或重复调用
最常被忽略的是：iOS 上哪怕你刚用 uni.setClipboardData 写入，紧接着读取仍会弹窗——系统不认“自己写的”，只认“当前是否被允许读”。这个设计让任何“写完立刻读”的乐观假设都不可靠。
