navigator.clipboard.writeText()必须由用户手势（如click、keydown）触发，否则抛NotAllowedError；仅支持纯文本，HTTPS/localhost安全上下文下可用，旧浏览器需降级至execCommand。
Clipboard API 写入文本必须走用户手势触发
直接调用 navigator.clipboard.writeText() 会失败，浏览器强制要求操作必须由用户主动触发（比如 click、keydown），否则抛出 NotAllowedError。这是安全限制，绕不过。
常见错误现象：在页面加载后自动执行、定时器里调用、或在异步回调（如 fetch 成功后）直接写剪贴板，都会报错。
- ✅ 正确做法：绑定到按钮的
click事件里 - ✅ 可以在
input的keydown中监听 Ctrl+C / Cmd+C 后立即写入替代内容 - ⚠️ 注意：
setTimeout延迟哪怕 0 毫秒也会脱离上下文，变成“非用户手势”
writeText() 和 write() 的关键区别
writeText() 只处理纯文本，简单直接；write() 支持写入图片、HTML 片段等富内容，但兼容性差、使用门槛高。
目前（2024 年主流浏览器）writeText() 已全平台支持（Chrome 66+、Firefox 63+、Safari 13.1+），而 write() 在 Safari 中仍不支持图片写入，且需手动构造 ClipboardItem。
立即学习“前端免费学习笔记（深入）”；
- ? 场景选型：只要复制文字，无条件用
writeText() - ?
write()需要Promise.all()包裹多个ClipboardItem，且每个 item 的types字段必须精确匹配 MIME 类型（如"text/html"、"image/png"） - ? 错误示例：
new ClipboardItem({ "text/plain": "hello" })会失败——value 必须是Blob或Promise<blob></blob>
读取剪贴板内容需额外权限和用户确认
navigator.clipboard.readText() 不像写入那样“静默”，首次调用时浏览器会弹出权限提示（Permission Prompt），用户拒绝后后续调用直接 reject。
而且它不能在所有上下文中运行：iframe 必须带 allow="clipboard-read" 属性，HTTP 页面在部分 Chrome 版本中会被降级为仅支持 HTTPS。
- ✅ 推荐先检查权限：
navigator.permissions.query({ name: "clipboard-read" }) - ✅ 错误捕获必须覆盖两种情况：
NotAllowedError（用户拒权）和NotFoundError（剪贴板为空或无文本格式） - ⚠️ 注意：
readText()返回的是字符串，但剪贴板里可能是 HTML 或富文本——它只会提取其中的纯文本部分，不会解析标签
兼容旧浏览器的降级方案怎么写
IE 和老版 Safari 完全不支持 Clipboard API，得回退到 document.execCommand("copy")，但它依赖 <textarea> 临时聚焦并选中内容，体验略糙。
关键点不是“有没有 API”，而是“能不能用”，所以判断逻辑应优先检测 navigator.clipboard 是否存在且方法可用，再 fallback。
- ✅ 判断写入能力：
if ("clipboard" in navigator && typeof navigator.clipboard.writeText === "function") - ✅ execCommand 方案中，
textarea必须插入 DOM、设置readonly、style.position = "fixed"防抖动，并在 copy 后立即remove() - ⚠️ 常见坑：Safari 13.0–13.0.4 中
writeText()存在 Promise 不 resolve 的 bug，需加setTimeout超时兜底并 fallback
allow 属性缺失——前者导致反复弹窗，后者让 API 直接静默失效。 
