uni-app无法区分剪贴板内容来源，因所有平台均不提供元信息；只能通过约定前缀、正则提取、用户确认等方式规避歧义，iOS 14+ 即使自写入也需单独授权读取。
uni-app 无法区分剪贴板内容是用户复制还是程序写入。这是平台层限制，不是 API 设计缺陷——所有主流平台（iOS、Android、微信小程序、H5）都不提供该能力，uni-app 作为跨端框架自然也无法突破。
为什么 uni.getClipboardData 拿不到来源信息
剪贴板本身是个纯数据容器，操作系统和浏览器只暴露 data 字段，不附带元信息（如时间戳、来源标记、调用者身份）。uni.getClipboardData 返回的 res.data 就是原始字符串，没有任何额外字段可用来判断“谁写的”。
常见误解：以为加个前缀或时间戳就能反向识别。但用户自己复制的内容也可能含类似格式，无法可靠区分。
实际开发中怎么应对这个限制
既然无法溯源，就只能靠策略规避歧义：
- 避免依赖“来源判断”，转而关注内容特征：比如约定程序写入时统一加前缀
[APP]，用户复制的内容通常不含该标记 - 读取后做清洗再匹配：
res.data.replace(/^[\[\]APP\s]+/, '').trim()，剥离程序标记后再业务处理 - 对关键操作（如邀请码填入）必须二次校验：不能仅凭剪贴板有值就自动提交，要结合正则提取 + 用户点击确认
- 不要在
onShow或定时轮询里无差别读取——既无效又触发 iOS 权限弹窗，还可能读到上一个页面残留的旧内容
鸿蒙和 App 端有没有例外
没有。鸿蒙（HarmonyOS）侧 uni.setClipboardData 和 uni.getClipboardData 行为与 Android 一致，同样不返回来源；App 端即使调用原生模块，系统 API 也未开放该字段。部分厂商定制 ROM（如华为 EMUI）反而更严格，连读取时机都受限，更别说来源标识。
真正容易被忽略的是：iOS 14+ 后，哪怕你刚用 uni.setClipboardData 写入，紧接着调 uni.getClipboardData 读出来，系统仍会弹授权提示——它不认“自己写的”，只认“当前是否被允许读”。
