iOS 14+首次调用uni.getClipboardData必弹系统授权框，仅用户点击事件同步触发有效，拒绝后无法重唤，需引导手动开启设置；H5不支持，小程序需配置permission；轮询监听基本不可行。
uni.getClipboardData在iOS 14+首次调用必弹系统授权框
iOS 14起，系统强制要求所有App读取剪贴板前必须获得用户明确授权，哪怕你已在manifest.json里勾选了「剪贴板」权限，uni.getClipboardData第一次执行时仍会弹出原生提示：“是否允许[你的App]访问剪贴板？”——这不是uni-app能绕过的，是系统级拦截。
这个弹窗只在首次调用时出现，且仅针对getClipboardData；setClipboardData写入操作不触发弹窗。
- 用户点“不允许”后，后续所有
uni.getClipboardData调用都静默失败：既不进success也不进fail，返回值为""，errMsg为"getClipboardData:fail auth deny" - 拒绝后无法通过代码再次唤起弹窗，
uni.authorize({scope: 'scope.writeClipboard'})在iOS上无效，该API不支持剪贴板权限申请 - 必须引导用户手动开启：跳转到「设置 → 隐私与安全性 → 剪贴板」，找到你的App并打开开关
iOS真机读取剪贴板失败的三个硬性前提
即使用户已授权，uni.getClipboardData仍可能返回空字符串，原因往往不是权限没开，而是调用时机或上下文不合法。
- 必须由用户点击事件（如
@tap="handlePaste"）**同步触发**：不能放在onLoad、onShow、setTimeout、Promise.then或async/await后续语句中，否则系统直接拦截 -
manifest.json必须勾选「剪贴板」：路径是「App 设置」→「iOS 设置」→「剪贴板」，勾选后**必须重新云打包**，本地运行或调试器不生效 - 读取结果可能含零宽字符：微信转发口令常带
\u200b等不可见符，导致data.trim().length === 0为false但视觉为空，建议统一清理：data.replace(/[\u200b-\u200f\u202a-\u202f]/g, '')
H5和小程序端不要混用同一套逻辑
uni.getClipboardData在H5平台完全不支持读取，调用后静默返回空；微信小程序虽支持，但行为和iOS原生不同——它不会弹系统级授权框，但要求你在manifest.json的mp-weixin节点下声明permission字段，否则真机报fail no permission。
- H5端应直接放弃
uni.getClipboardData，浏览器策略禁止读取剪贴板，连navigator.clipboard.readText也只在极少数HTTPS+安全上下文+用户手势场景下可用，且兼容性差 - 小程序端若漏配
"scope.writeClipboard"权限，iOS真机会直接拒绝，连弹窗都不给；Android则可能静默失败或返回空 - 跨端代码里别用
process.env.UNI_PLATFORM === 'app'粗暴判断，要拆成ios、mp-weixin、h5三路分别处理
轮询监听剪贴板变化在iOS上基本不可行
业务想实现“自动识别邀请码”，试图用setInterval反复调uni.getClipboardData——这在iOS上效果极差。系统对后台/非焦点App的剪贴板访问限制极严，且频繁读取可能触发系统警告或被挂起。
- iOS App切到后台后，定时器大概率被系统暂停，轮询失效
- 即使前台运行，800ms–1500ms间隔仍可能被系统限频，尤其在低电量模式下
- 首次调用若被拒，后续所有轮询都拿不到新内容，但你无法感知拒绝状态，容易陷入无限空读
- 真正可行的方案只有“一键读取”：按钮触发
uni.getClipboardData，成功后做正则匹配，再由用户决定是否使用
