Clipboard API 如何复制和读取剪贴板？有哪些权限限制？

简化版

Clipboard API 通过 navigator.clipboard.writeText/readText 复制或读取剪贴板，通常要求 HTTPS、安全上下文和用户手势。复制相对常见，读取更敏感，必须处理权限、失败兜底、兼容方案和隐私风险。

详细版

常见使用：

• 点击按钮复制链接、邀请码、命令。
• 粘贴验证码、图片或文本。
• 富文本编辑器读写剪贴板。

注意点：

• 通常需要 HTTPS。
• 复制最好由用户点击触发。
• 读取剪贴板更敏感，浏览器权限限制更严格。
• API 失败时要提示用户手动复制。
• 不要偷偷读取剪贴板内容。
• 老浏览器可能需要降级方案。

完整版教学

一、剪贴板是敏感能力

剪贴板里可能有密码、验证码、银行卡号、私密聊天内容。浏览器不能允许网页随便读取，否则任何页面都能偷用户剪贴板。因此 Clipboard API 有安全上下文、权限和用户手势限制。

复制操作风险相对低，因为用户通常主动点击“复制”；读取操作风险高，因为它把用户已有剪贴板内容暴露给页面。面试回答时要把安全和隐私放在 API 前面。

复制：网页 → 剪贴板
读取：剪贴板 → 网页（更敏感）

二、现代复制 API 怎么用

现代浏览器推荐使用 navigator.clipboard.writeText。它是异步 API，成功后给用户反馈，失败时进入兜底。不要复制后毫无提示，用户不知道是否成功。

async function copyInvite(text) {
  try {
    await navigator.clipboard.writeText(text)
    showToast('已复制')
  } catch {
    showManualCopyDialog(text)
  }
}

如果复制内容是链接或邀请码，最好展示明文，让用户确认复制的是什么。复制敏感内容时要避免写入日志。

三、读取剪贴板限制更强

readText 可能要求权限、用户手势或浏览器提示。不同浏览器策略不同，尤其移动端差异明显。业务上不应依赖“页面加载后自动读取剪贴板”，这既可能失败，也会让用户反感。

更合适的交互是用户点击“粘贴验证码”按钮，页面再尝试读取。如果失败，就让用户手动粘贴。这样权限请求和用户意图一致。

操作	风险	交互建议
写入文本	中低	点击复制后提示
读取文本	高	用户点击粘贴后读取
写入图片/富文本	中	明确说明内容
自动读取	高	尽量避免

四、兼容和兜底不能省

有些浏览器、WebView 或旧环境不支持 Clipboard API。复制功能通常可以用选中文本、提示长按复制或旧方案降级。读取功能如果失败，就只能让用户手动粘贴，不应阻塞主流程。

数字例子：如果复制按钮成功率 98%，剩下 2% 用户没有兜底；一个月 100000 次复制就有 2000 次失败体验。对邀请码、支付账号、客服微信这类关键复制场景，兜底很有必要。

五、用户手势和异步链路要注意

浏览器常要求剪贴板操作发生在用户手势触发的调用链中。如果点击按钮后先等待一个很久的异步请求，再复制，某些环境可能认为用户激活已失效。更稳的做法是先准备好要复制的内容，点击时直接调用复制。

例如邀请链接可以提前生成，按钮点击时只执行 writeText。如果必须异步生成，也要处理失败，并允许用户再次点击复制。

六、隐私设计要克制

不要为了“自动识别验证码”而偷偷读取剪贴板。即使浏览器允许，也会损害信任。读取前说明用途，读取后只使用必要内容，并避免上报原始剪贴板。

比如粘贴口令时，只需要判断是否符合你的口令格式，不要把整个剪贴板文本上传。对不匹配内容应在本地丢弃。

记忆钩子：剪贴板 API 的第一原则是“用户知道并主动触发”，不是技术上能读就读。

七、常见误区与追问

• 误区：Clipboard API 在所有环境都能用。 它通常要求 HTTPS、安全上下文和浏览器支持。
• 误区：读取剪贴板和复制一样简单。 读取更敏感，权限和用户手势限制更严格。
• 误区：复制失败可以忽略。 关键业务需要手动复制兜底和明确提示。
• 追问：为什么本地 HTTP 调试可用但线上 WebView 不行？ 环境安全上下文、权限策略和宿主限制可能不同。
• 追问：如何设计粘贴验证码体验？ 用户点击粘贴按钮后读取，失败则聚焦输入框让用户手动粘贴。
• 追问：能不能自动读取用户剪贴板？ 不建议，隐私风险高，也容易被浏览器限制。

八、加强记忆

Clipboard API 用“安全上下文、用户手势、读取更敏感、失败有兜底”来记。复制链接和邀请码要给反馈，读取剪贴板要明确用户意图，兼容失败要允许手动操作，隐私内容不要偷偷读取或上报。