复制按钮的"假成功"陷阱：我复现了HN热帖的沉默Bug|上下文|代码|剪贴板

你刚点了"复制密钥"，看到绿色对勾，自信地粘贴进终端——结果跑的是上一条命令。这不是你的错，是按钮在撒谎。

我在集成一个"复制令牌"功能时撞上了这个坑。Clipboard API（剪贴板接口）返回了undefined，控制台却干干净净。用户会看见成功提示，剪贴板里却空空如也，或者更糟：留着之前的东西。在那个场景下，"之前的东西"可能是任何东西。

这让我想起Hacker News上那篇977赞的热帖《Copy Fail》。作者记录了navigator.clipboard.writeText()在特定场景下静默失败的怪象：没异常、没拒绝、没动静。用户点击，图标变对勾，剪贴板原封不动。

帖子的回复区炸了。有人说是Chromium的权限模型，有人怪iframe，有人说文档没聚焦。都对，也都不全。

我的判断：问题不是剪贴板会失败，而是我们的UX（用户体验）假装它不会失败。当复制的是密码、API密钥、私钥时，这种假装尤其危险。

我在自己的环境里复现了一遍。发现的东西比原帖更麻烦。

三个场景，三种失败姿势

我打开了一个生产环境跑着的组件——一个复制API密钥的管理后台按钮。技术栈：Next.js 15、TypeScript，Railway部署，前面挂着反向代理。

第一个意外：bug不是到处都一样。我需要三个不同场景才能摸清全貌。

场景一，iframe陷阱。组件如果嵌在iframe里，缺了allow="clipboard-write"属性，writeText()的Promise（Promise对象，异步操作占位符）会resolve（解决，即完成状态）但不做事。代码继续跑，setCopied(true)照样执行，用户看见绿对勾。

场景二，权限静默拒绝。某些浏览器上下文里，权限查询返回"prompt"（询问）状态，用户却看不到任何弹窗。writeText()直接resolve成undefined，没有异常抛到catch块。

场景三，焦点争夺。浏览器要求文档有用户激活（user activation，用户近期交互状态）才能写剪贴板。但"近期"的定义各浏览器不同：Chrome是1秒内，Safari是5秒内，Firefox看心情。超时后调用，静默失败。

最阴险的是场景一和二的组合：权限系统说"可以试"，writeText()说"好的我试了"，实际什么都没写。你的错误处理代码永远跑不到。

为什么错误处理会失效

我加了显式日志才看清真相。标准try-catch（异常捕获结构）在这里是摆设：

// 这种写法在场景一、二下抓不到任何东西
try {
await navigator.clipboard.writeText(token);
setCopied(true);
} catch (err) {
// 永远不会到这里
showError();
}

问题出在Promise的resolve语义。API规范允许writeText()在"无法执行但不算错误"时resolve为undefined。这不是reject（拒绝，即失败状态），所以catch不触发。

我被迫写成防御性代码：先查权限，再试写入，最后验证结果。三步才能确定"成功"是真的成功。

// 至少不说谎的版本
async function copiarTokenSeguro(token: string): Promise {
// 第一步：权限预检
const permiso = await navigator.permissions.query({
name: "clipboard-write" as PermissionName,
});
if (permiso.state === "denied") return fallback(token);

// 第二步：尝试写入
const result = await navigator.clipboard.writeText(token);

// 第三步：验证（关键！）
const verification = await navigator.clipboard.readText();
return verification === token;
}

第三步是原帖没提的。readText()验证看似聪明，却引来新问题：需要"clipboard-read"权限，而某些安全上下文里这个权限比write还难拿。

产品层面的连锁反应

这个技术细节逼着我在产品层做选择。验证失败时怎么办？

选项A：隐藏复制按钮，没权限就不给用。干净，但用户困惑——"为什么别人的界面有这按钮？"

选项B：降级到execCommand('copy')，老API兼容性更好，但已被标记废弃，未来可能移除。

选项C：保留按钮，点击后弹模态框教用户手动选中文本复制。体验差，但绝对可靠。

我最后选了动态策略：先测Clipboard API，不行再试execCommand，再不行才出模态框。代码复杂度翻三倍，只为一个"复制"按钮。

更隐蔽的成本在数据埋点。以前我记录"复制成功"事件是在writeText() resolve后。现在这数据是垃圾——resolve不等于真写了。要准确统计，得等验证通过，或者改记"用户完成粘贴后主动关闭提示"这种代理指标。

这还影响了A/B测试的设计。如果我想测"复制按钮放左边还是右边转化率高"，现在得确保两组用户的权限上下文分布一致。iframe嵌套深度、浏览器类型、用户之前是否点过"允许"，都成了混杂变量。

从Bug看平台权力