轮询读取剪贴板被系统拦截时，应设≥1200ms间隔、仅在onshow启动并onhide清除，加1s超时检测与连续3次失败后暂停30秒；android需用native.js确认前台状态，ios首次授权后须重置轮询状态，持续无响应则降级为手动触发。
uni-app 轮询读取剪贴板被系统拦截怎么办
App 端无法监听剪贴板变化，轮询是唯一可行的模拟方案，但 iOS 和 Android 厂商（尤其华为、小米）会主动拦截高频或后台轮询——不是代码写错了，而是系统直接静默拒绝调用，uni.getClipboardData 既不进 success 也不进 fail，Promise 卡在 pending 状态。
- 轮询间隔必须 ≥ 800ms，推荐 1200–1500ms；低于 500ms 在 iOS 16+ 和 Android 12+ 上大概率被限频或终止
- 只在页面
onShow启动定时器，onHide或onUnload中clearInterval，切到后台后继续轮询会被系统标记为异常行为 - 避免在
onLoad阶段就启动——部分安卓 WebView 和 iOS Safari 会返回旧值或空字符串，等页面真正渲染完成再开始更可靠 - 每次读取前加长度预检：
if (this.lastClipLength > 1000) return;，超长内容大概率是广告或日志，没必要反复比对
怎么判断轮询是否已被系统拦截
不能只看返回值是否为空——真正的拦截表现是“无响应”：既没有 success 回调，也没有 fail 回调，控制台也无报错。这时候你需要主动探测。
- 给
uni.getClipboardData加超时控制：用Promise.race([fetch, new Promise(r => setTimeout(r, 1000))])，1s 内没结果就视为被拦截 - 记录连续失败次数，超过 3 次就暂停轮询 30 秒，并提示用户“检测到剪贴板访问受限，请稍后再试”
- 对比前后两次读取的
data字符串引用或哈希值，而不是只比length——有些系统会返回缓存副本，看着一样但实际没更新
Android 厂商定制系统下怎么降低拦截概率
华为 EMUI、小米 MIUI、OPPO ColorOS 对后台剪贴板访问极其敏感，即使 App 在前台，若用户切换过应用或锁屏再回来，也可能触发临时封禁。
- 每次轮询前先调用
uni.getSystemInfoSync().platform，对android平台额外加一层「活跃窗口」判断：用plus.navigator.hasFocus()（需启用 Native.js）确认当前 WebView 是否真正在前台 - 避开低电量模式：通过
plus.power.getBatteryState()检测，若为low或unplugged，自动将轮询间隔拉长至 3000ms - 不要复用同一个
success回调函数地址——部分厂商会缓存回调引用并做去重，改用箭头函数或每次生成新闭包可绕过
iOS 上轮询触发授权弹窗后反而失效
iOS 14+ 首次调用 uni.getClipboardData 必弹系统授权弹窗，但用户点「允许」后，如果轮询逻辑没重置状态，后续请求可能仍返回空——不是权限问题，而是系统对非用户手势上下文的二次限制。
- 首次成功读取后，必须重置轮询计数器和缓存值，否则系统可能把后续轮询识别为“非交互行为”而拦截
- 不要在
success回调里立刻再次setTimeout下一轮；改为this.$nextTick(() => this.startPolling())，确保 DOM 更新完成后再继续 - 若用户点了「不允许」，iOS 会永久记住该选择，
uni.getClipboardData后续调用完全静默；此时应停止轮询，并显示明确引导：“请前往「设置 → 隐私与安全性 → 剪贴板」开启权限”
