应优先使用 navigator.clipboard.writeText()，document.execCommand('copy') 已废弃；仅在需兼容 IE11 或老旧 WebView 时降级使用，且须配合能力检测、安全上下文判断与用户手势约束。
直接结论：现在该用 navigator.clipboard.writeText()，document.execCommand('copy') 已废弃，仅在必须兼容 IE11 或极老安卓 WebView 时才考虑降级 fallback。
为什么 execCommand 复制会突然失效
很多老项目里还留着 textArea.select(); document.execCommand('copy') 这套逻辑，但它在现代浏览器中越来越容易失败。原因不是代码写错了，而是浏览器主动拦截了：
- Chrome 85+、Firefox 90+、Safari 16.4+ 默认禁止非用户手势（如
click、keydown）触发的execCommand调用 - 即使有用户点击，若页面没用 HTTPS（localhost 除外），部分浏览器会静默拒绝
-
execCommand是同步阻塞操作，复制大段 HTML 或含图片的富文本时，主线程卡顿明显，控制台可能报Failed to execute 'execCommand' on 'Document' - 它依赖 DOM 操作（动态插入隐藏
textarea、select()、removeAllRanges()），任意一环出错就失败，且错误不明确
Clipboard API 的真实使用门槛
navigator.clipboard.writeText() 看起来干净，但实际部署时几个条件缺一不可：
- 必须运行在安全上下文（HTTPS 或
localhost），HTTP 页面直接调用会抛SecurityError - 必须在用户交互事件回调内调用（比如
click、input），不能在setTimeout或异步请求回调里直接调用 - 移动端（尤其是 iOS Safari）首次调用时会弹权限提示，用户点“不允许”后，后续调用会进
catch，且不会再次提示——这个状态无法通过 JS 主动重置 - Firefox 仅支持
writeText()，不支持write()（即无法写入图片或 HTML 片段）；Safari 对write()的支持仍不稳定
示例中常见的错误写法：fetch('/api/text').then(res => res.text()).then(text => navigator.clipboard.writeText(text)) —— 这个 writeText 不在用户手势链内，必失败。
立即学习“前端免费学习笔记（深入）”；
如何安全地 fallback 到 execCommand
不是“先试 Clipboard，失败再 execCommand”，而是按能力检测 + 场景隔离来设计：
- 先检查
navigator.clipboard是否存在且writeText可调用，再检查是否在安全上下文（location.protocol === 'https:' || location.hostname === 'localhost'） - 只对纯文本复制走 Clipboard；如果要复制带样式的 HTML（比如富文本编辑器内容），仍需降级到
execCommand+div[contenteditable]方案（注意：Safari 对contenteditable的select支持更可靠） - execCommand 降级代码里必须加
try/catch，并兜底提示：“请手动 Ctrl+C 复制”，避免静默失败 - 不要在同一个按钮点击事件里混用两种 API；明确区分：现代环境用
clipboard，旧环境（如 IE11、Android 4.4 WebView）才走execCommand
一个典型判断逻辑：if ('clipboard' in navigator && window.isSecureContext) { /* 用 writeText */ } else { /* 用 execCommand + textarea */ }
复制 HTML 片段时最常被忽略的点
很多人想一键复制一段带样式、图片的 HTML（比如分享卡片），但 writeText() 只接受字符串，write() 要求构造 ClipboardItem，而浏览器支持度参差不齐：
- Chrome 支持
write(new ClipboardItem({ 'text/html': new Blob([htmlStr], {type: 'text/html'}) })) - Safari 目前不支持
text/html类型写入，只能退回到execCommand+div[contenteditable]模拟选中 - Firefox 完全不支持
write()，所以 HTML 复制在 Firefox 中基本只能靠execCommand或引导用户右键 - 即便成功写入
text/html，粘贴到微信、钉钉等客户端时，往往被自动过滤为纯文本——这不是前端能控制的，得提前告知用户预期
真正稳定的方案是：纯文本走 writeText，HTML 内容优先生成 PNG（用 html2canvas），再用 write() 写入 image/png blob——但这已超出“一键复制”的简单范畴，属于图像化导出流程。
