复制失败常因CSS禁用选中（user-select:none），需移除或JS临时设为text；推荐navigator.clipboard.writeText()，但需HTTPS、用户手势触发；旧浏览器可降级execCommand。
复制文本前必须确保元素可选中
很多情况下点击按钮没反应，不是代码问题，而是目标文本所在的 <div> 或 <code><span></span> 被 CSS 禁用了选中，比如写了 user-select: none 或 -webkit-user-select: none。浏览器的 document.execCommand('copy') 和现代 navigator.clipboard.writeText() 都不依赖“是否可见”，但前者要求内容先被选中——而选中失败就直接卡住。
解决方法很简单：
- 检查目标容器的 CSS，移除或临时覆盖
user-select相关声明 - 如果不能改样式，可在复制前用 JS 强制设置：
element.style.userSelect = 'text';
- 对
<input>或<textarea></textarea>元素，只要没加readonly或disabled，通常没问题
推荐用 navigator.clipboard.writeText() 而非 execCommand
document.execCommand('copy') 已被废弃，Chrome 90+ 在非用户手势（如 setTimeout 触发）下调用会静默失败；而 navigator.clipboard.writeText() 是现代标准，返回 Promise，便于处理成功/失败。
但要注意权限限制：
立即学习“Java免费学习笔记（深入）”；
- 只在安全上下文（
https://或localhost）中可用 - 必须由用户手势触发（如
click、keydown），不能在异步回调里直接调用 - 首次调用会弹出浏览器权限提示（仅 Chrome/Firefox），后续自动授权
基础用法示例：
button.addEventListener('click', async () => {
try {
await navigator.clipboard.writeText('要复制的内容');
console.log('复制成功');
} catch (err) {
console.error('复制失败:', err);
}
});
兼容旧版浏览器需降级到 execCommand
如果必须支持 IE11 或老版 Safari（navigator.clipboard 未定义），得回退到 execCommand 方案。它需要先创建临时 <textarea></textarea>，聚焦、选中、再执行复制。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
关键细节：
- 临时元素必须添加到
document.body，否则部分浏览器不识别 - 要设
style.position = 'fixed'并隐藏（left: '-9999px'），避免页面跳动 - 执行完记得
remove()，否则内存泄漏风险小但存在
简易降级写法：
function copyText(text) {
if (navigator.clipboard && window.isSecureContext) {
return navigator.clipboard.writeText(text);
}
const textarea = document.createElement('textarea');
textarea.value = text;
textarea.style.position = 'fixed';
textarea.style.left = '-9999px';
document.body.appendChild(textarea);
textarea.focus();
textarea.select();
const result = document.execCommand('copy');
document.body.removeChild(textarea);
return Promise.resolve(result);
}
复制长文本或富文本要额外处理
纯文本复制用 writeText() 就够了；但如果想复制带样式的 HTML 片段（比如高亮代码块），就得用 navigator.clipboard.write() 配合 ClipboardItem，且目前仅 Chromium 内核稳定支持。
常见陷阱：
-
ClipboardItem构造时，MIME 类型必须严格匹配内容，如 HTML 必须是'text/html'，不能写成'html' - 传入的 blob 需是
new Blob([htmlString], { type: 'text/html' })，不能直接传字符串 - 移动端 Safari 完全不支持
write()，连降级方案都不行，只能降级为纯文本
所以实际项目中，除非明确需要 HTML 粘贴到 Word/Notion 等支持富文本的编辑器，否则坚持用 writeText() 更稳妥。
复杂逻辑往往卡在权限、上下文、DOM 状态这些地方，而不是 API 本身。调试时优先确认：是不是 HTTPS？是不是用户点的？目标元素能不能被选中？
