ios首次调用uni.getclipboarddata会弹系统弹窗，用户点“不允许”后所有调用均静默返回空字符串且无报错，无法通过uni.opensetting跳转设置页，唯一解法是引导用户手动开启权限。
uni.getClipboardData 返回空且无报错，大概率是用户点了“不允许”
iOS 系统对剪贴板读取有强干预机制：首次调用 uni.getClipboardData 一定会弹系统级弹窗，用户点「不允许」后，后续所有调用都静默失败——既不进 success，也不进 fail，res.data 就是空字符串，控制台安静如鸡。
这不是 bug，是 iOS 14+ 的硬性限制。你无法用代码触发第二次弹窗，也无法通过 uni.authorize 或 uni.openSetting 拉起权限页（iOS 不支持该 API 对剪贴板的设置跳转）。
- 验证方式：在回调里加
console.log(JSON.stringify(res))，如果输出{"data":"","errMsg":"getClipboardData:ok"}，基本可确认是被拒绝后静默返回 - 用户必须手动去「设置 → 隐私与安全性 → 剪贴板」里找到你的 App，把开关打开
- 可在检测到空内容时，用
uni.showModal提示：“请前往系统设置开启剪贴板权限，否则无法粘贴口令”
为什么 uni.openSetting 在 iOS 上对剪贴板无效
uni.openSetting 在 iOS 原生端只支持有限几类权限（如定位、相册），剪贴板不在其中。调用它不会跳转到对应设置项，也不会报错，只是白忙活。
微信小程序虽支持 openSetting 并能展示剪贴板开关，但那是小程序框架层做的映射；App 端（即 uni-app 打包的 iOS 原生 App）走的是 UIKit 原生路径，系统根本不提供这个入口。
- 别写
uni.getSetting().then(...).openSetting()这类链式兜底逻辑，iOS 上完全没用 - manifest.json 里已勾选「剪贴板」权限，只影响首次能否弹窗，不影响拒绝后的恢复路径
- 唯一可行的引导动作：用文字 + 截图示意用户路径，或跳转到系统设置首页（
uni.navigateTo({ url: 'pages/setting-tips' })）
读取前要不要先 check 权限状态？没必要
iOS 没有公开的 API 能提前判断剪贴板是否已被用户拒绝。调用 uni.getSetting 返回的 authSetting 里压根不包含 scope.userclipboardread 字段——它不像定位或相册那样暴露状态。
所以你没法像处理 scope.userLocation 那样做三态判断（undefined/true/false）。一切检测都得靠读取结果反推。
- 直接调用
uni.getClipboardData，然后检查res.data是否为空、是否含零宽字符（u200b等） - 如果
res.data.trim() === ''且JSON.stringify(res.data).includes('\u200b')为 false，才大概率是权限被拒 - 别在
onShow或onLoad里预检，那会因上下文非法直接失败，反而掩盖真实问题
容易被忽略的“二次污染”场景
用户第一次拒绝后，即使后来去设置里打开了开关，部分 iOS 版本（尤其是 17.x）仍可能缓存拒绝状态，导致下一次读取还是空。这不是你的代码问题，而是系统行为。
更隐蔽的是：如果用户从微信复制了一段带零宽字符的口令，再点你的“粘贴”按钮，uni.getClipboardData 会成功返回，但 res.data 看着像空——因为 trim() 清不掉 u200b，length 却大于 0。
- 清理逻辑必须加：
res.data.replace(/[u200b-u200fu202a-u202fuFEFF]/g, '').trim() - 别只依赖
res.data === ''判断失败，要结合JSON.stringify和正则检测 - 权限被拒和内容污染的表现高度相似，排查时务必分两步：先清污染，再看是否仍为空
