用户在 H5 看到一篇内容或一条邀请，点击下载 App。应用安装完成后，原网页已经关闭，系统如何知道用户来自哪个渠道，又该打开哪篇内容？
剪贴板归因提供了一条简单的“跨安装信道”：H5 把来源信息写入系统剪贴板，App 首次打开时读取并匹配，从而恢复渠道、活动或目标内容。
它不依赖设备 ID，也不要求应用商店回传参数，曾广泛用于裂变邀请、内容分享和 Web-to-App 承接。但在今天，“H5 静默写入、App 静默读取”的方案已经不可靠，也不符合平台强调用户知情的方向。
正确的链路：剪贴板只传一次性令牌
不要把渠道、用户 ID、手机号或目标 URL 全部明文塞进剪贴板。更稳妥的设计是：
- 用户点击 H5 上的“复制口令并下载”；服务端生成随机令牌，例如
a7K9mP，保存其对应的渠道、活动、邀请人和目标内容； - 页面在用户操作后把令牌写入剪贴板，再跳转应用商店或下载页；
- App 首次打开时，通过系统认可的粘贴交互取得令牌并提交服务端；
- 服务端校验签名、有效期和使用次数，返回归因结果与目标内容；
- 令牌核销后立即失效，App 清理本地临时数据。
这样做有三个好处：剪贴板泄露时不暴露真实业务数据；令牌可以过期和单次核销；归因规则留在服务端，方便去重、反作弊和调整。
哪些业务适合？
剪贴板归因更适合用户主动触发、安装链路较短、需要承接上下文的场景：
- 邀请好友、拼团、助力等裂变活动，需要安装后还原邀请关系；
- 文章、商品、课程或直播间分享，需要安装后打开指定内容；
- 公众号、社群和普通 H5 导流，媒体无法提供设备 ID 或安装回传；
- 私域活动或线下二维码，需要用轻量口令区分活动来源。
早期的知乎分享案例，本质就是把答案 ID、来源和活动参数写入剪贴板，再由网页或 App 读取并恢复内容。
它不适合大规模广告结算、长期归因或必须无感完成的流程。只要平台已经提供 Install Referrer、Campaign Links、AdAttributionKit 或可靠的延迟深度链接，就应优先使用官方链路。
当前系统限制已经改变
iOS：读取动作必须让用户看得见
iOS 14 起，App 在没有明确用户意图时读取其他 App 写入的通用剪贴板，系统会通知用户。iOS 16 起，程序化粘贴会弹出授权提示；使用系统提供的 UIPasteControl，让用户主动点击粘贴，才能获得更自然的体验。
App 可以先用 Pattern Detection 判断剪贴板是否包含链接等系统支持的类型，而不读取具体内容；但它无法识别任意自定义口令，真正取得令牌仍应依赖用户授权。不要在启动页反复探测和读取，否则既打扰用户，也会损害信任。
Android：不能再把剪贴板当后台公共存储
Android 10 起，除默认输入法外，不在前台的 App 不能读取剪贴板。首次启动的 App 虽处于前台，但仍应在明确业务场景下读取。Android 13 及以上还会在内容复制时展示系统预览，用户能够看到页面写入了什么。
H5：写入也不是必然成功
Web Clipboard API 通常要求 HTTPS，浏览器还可能要求用户点击、授权或采用自己的粘贴交互。微信内置浏览器、Safari、Chrome 以及不同系统版本的行为并不完全一致，因此必须检测写入结果，失败时展示可手动复制的口令。
五个容易踩的坑
- 内容被覆盖：用户安装前复制了地址、验证码，令牌就会丢失；
- 重复归因：旧令牌未核销，二次打开又被使用；
- 串单作弊：同一口令被大量转发，虚增某个邀请人或渠道；
- 读取过度：直接上传完整剪贴板，可能收集密码、地址等无关敏感信息；
- 没有降级：写入、读取或授权任一步失败，用户无法继续原任务。
对应的治理并不复杂：令牌随机且不可猜；设置短有效期和单次使用；限制同令牌、设备和账号的核销频率；服务端只接收符合固定格式的口令；无令牌时回到首页、搜索页或让用户手动输入；监控写入成功率、读取授权率、核销率和异常复用率。
剪贴板归因没有彻底失效，但它已经从“无感桥梁”变成了“用户主动参与的兜底通道”。把剪贴板只当作短期令牌载体，而不是隐蔽的数据接口，才能同时保住转化链路、用户信任和平台合规。