轮询间隔建议设为800ms–1500ms，太短会增加CPU和电量消耗，太长易漏掉短时操作；须在onShow启动、onHide清除定时器，避免后台运行或重复启动。
uni.getClipboardData 轮询间隔设多少合适
轮询间隔不是越短越好，800ms–1500ms 是实测较平衡的范围。太密（如 100ms）会显著增加 CPU 占用和耗电，尤其在 iOS 后台被系统限制后反而更不可靠；太松（如 5000ms）容易漏掉用户快速连续复制的操作，比如复制链接 → 立刻复制口令 → 立刻粘贴，中间只差 1 秒。
为什么不能在 onLoad 或 onShow 里直接启动轮询
因为 iOS 和 Android 对后台/非活跃页面的剪贴板访问有强限制：切到后台后定时器可能被 suspend，甚至直接 kill；onLoad 时页面未完全渲染，部分平台（尤其是 iOS）会返回空或旧值；onShow 虽然页面可见，但若用户从其他 App 切回，系统可能尚未恢复剪贴板读取能力。
- 必须在
onShow中调用startPolling，且该函数内要先清除已有定时器（防重复启动） - 必须在
onHide中调用clearInterval清除定时器，否则切后台后仍可能触发读取并报错 - 首次读取失败时不要立即重试，建议加个 300ms 延迟再读一次——iOS 首次调用常因权限弹窗未完成而返回空
轮询时怎么避免重复触发识别逻辑
单纯比对字符串是否变化容易误判：比如用户复制了带零宽空格（\u200b）的内容，肉眼看起来一样，但字符串不等；又或者连续复制同一段文本，不该反复触发“新内容”逻辑。
- 每次读取后先做清洗：
data.replace(/[\u200b-\u200f\u202a-\u202f]/g, '').trim() - 用
JSON.stringify序列化当前值与上一次清洗后的值做严格比对，而非== - 缓存上一次有效内容用
this.lastClipboardValue，别存在局部变量里，否则闭包中拿不到最新值
鸿蒙和小程序平台要注意什么
鸿蒙虽支持 ohos.permission.READ_PASTEBOARD，但不提供剪贴板变更广播，轮询仍是唯一方式；微信/支付宝小程序则受限于基础库版本——低版本（如微信
- 鸿蒙端轮询间隔建议 ≥1200ms，避免频繁触发
getClipboardData导致系统限频 - 小程序端需在
fail回调里判断err.errMsg是否含auth deny，是则引导用户去设置页手动开启 - 所有平台都禁止在轮询中调用
uni.showToast等 UI 提示——它会打断轮询节奏，且 iOS 下可能触发视图重绘卡顿
