uni-app 无法直接监听剪贴板变化，官方仅支持一次性读取；app端可通过native.js轮询或原生桥接近似实现，h5和小程序必须由用户手势触发主动读取，且受限于平台策略与安全限制。
uni-app 无法直接监听剪贴板变化
官方 uni.getClipboardData 是一次性读取，没有事件、没有回调、不支持监听。所谓“监听”在 uni-app 中本质是轮询或原生桥接，跨端方案必须拆开处理。
App 端可用 Native.js 实现近似监听
仅限 App（iOS/Android），需用 plus.android 或 plus.ios 调用原生剪贴板 API，配合定时轮询或系统级监听器。H5 和小程序完全不可行。
- Android 示例：用
plus.android.invoke(clip, "getPrimaryClip")获取当前 ClipData，再比对内容是否变化 - iOS 示例：需通过
plus.ios.importClass("UIPasteboard")获取generalPasteboard，调用string属性读取 - 轮询必须配对
onShow/onHide启停，否则后台持续占用 CPU - 首次获取失败时，不要立即重试——原生剪贴板可能尚未就绪，建议延迟 300ms 再读
H5 和小程序只能靠“用户触发 + 主动读取”
浏览器和小程序平台禁止后台静默读取剪贴板，所有读取必须由用户手势（click、tap）直接触发，且不能包裹异步逻辑。
- H5 必须用
navigator.clipboard.readText()，但只在 HTTPS / localhost 下有效；http://192.168.x.x本地调试会抛NotAllowedError - 微信小程序需在
manifest.json中声明"scope.writeClipboard"权限，否则uni.getClipboardData在 iOS 真机返回空字符串 - 读到的内容可能含零宽字符（如
\u200b），建议统一用data.replace(/[\u200b-\u200f\u202a-\u202f]/g, '')清洗 - 不要在
onLoad或setTimeout里调用——微信强制要求“点击按钮后同步执行”，否则静默失败
轮询实现要注意的三个硬伤
即使 App 端用 Native.js 轮询，也容易掉进性能、兼容、时机三重坑里：
- 轮询间隔不能低于 500ms，太密会导致 Android WebView 卡顿、iOS 崩溃概率上升
- 部分安卓机型（如旧版华为 EMUI）对
ClipData.getItemAt(0).getText()返回 null，需加 try/catch 并 fallback 到旧接口 -
lastClipboard变量若没做深比较（比如只比引用），遇到相同文本不同格式（换行符、全角空格）会误判为“未变化”
真正需要实时感知剪贴板的场景（比如扫码口令自动识别），优先考虑让用户点击“粘贴”按钮，而不是执着于后台监听——后者既难稳定，又易被平台限制或用户拒绝。
