点击“复制”，页面立刻提示成功，但写入随后被拒绝，用户粘贴出来的仍是旧内容。问题可能出在提示时机：点击发生了，只能说明用户发起了操作，不能说明剪贴板已经更新。
以米米商聊为背景，已整理的手机端资料包含消息“复制”操作。本文借这一交互讨论浏览器纯文本复制，不断言产品存在下述问题，也不推断原生 App 的剪贴板接口或产品内部实现。代码与文本均为独立合成示例。
1. 点击、写入完成和粘贴成功不是同一件事
浏览器的 navigator.clipboard.writeText() 返回一个 Promise。根据 MDN 的 writeText 文档，它在剪贴板更新完成后兑现，也可能因不允许写入而失败。因此，不应在调用后立刻无条件显示“已复制”。
界面至少需要区分等待、完成和失败。失败后保留可重试或手动复制的入口，比继续显示成功更符合实际结果。即使本次写入完成，也不能据此声称用户已经粘贴到其他应用，或剪贴板之后不会再被改写。
连续点击又带来另一项约定：本例在一次写入尚未完成时，拒绝同一控制器上的新复制请求，不排队、不自动补写。这样能让每次被执行的复制都对应明确的发起动作。
2. 先把能力、输入和执行结果分开
本例将写入函数作为依赖传入，函数应返回 Promise 或可等待的 thenable。缺少写入能力、没有文本、正在等待和写入失败，分别返回不同状态。
| 返回状态 | 本例中的含义 | 界面不应做的事 |
|---|---|---|
copied |
本次写入依赖已完成 | 推断其他应用已经粘贴 |
failed |
写入抛错、拒绝或适配器返回不合约 | 继续显示成功 |
busy |
同一控制器仍有写入在等待 | 认为本次请求已经排入队列 |
empty |
输入是空字符串，未发起写入 | 默默把剪贴板清空 |
unavailable |
未提供写入能力 | 假装调用了浏览器接口 |
空字符串不执行写入是本例的交互选择，不是浏览器 API 的限制。只含空格、制表符或换行的非空文本会原样传递，不会先 trim()。复制消息时，是否保留空白应由明确的内容规则决定，不能在反馈函数里悄悄改写文本。
3. 一个只管理单次写入的控制器
下面代码没有访问浏览器或系统剪贴板。它只负责输入检查、等待状态和执行结果；真正的写入由调用方提供。
function createCopyAction(writeText) {
if (writeText !== undefined && typeof writeText !== "function") {
throw new TypeError("writeText must be a function or undefined");
}
let pending = false;
return {
isPending() {
return pending;
},
async copy(text) {
if (typeof text !== "string") throw new TypeError("text must be a string");
if (text.length === 0) return "empty";
if (writeText === undefined) return "unavailable";
if (pending) return "busy";
pending = true;
try {
const operation = writeText(text);
if (operation === null || operation === undefined
|| typeof operation.then !== "function") {
throw new TypeError("writeText must return an awaitable");
}
await operation;
return "copied";
} catch {
return "failed";
} finally {
pending = false;
}
}
};
}
pending 在调用写入函数之前就置为 true，而不是等一个异步步骤结束后才登记。写入函数在 copy() 的这次调用中直接执行；等待发生在取得它的返回值之后。
兑现、拒绝和同步抛错都会结束本次等待，并通过 finally 释放状态。非字符串输入属于调用方错误，会拒绝返回的 Promise；接入层仍需处理它，不能把所有编程错误都变成普通“复制失败”提示。
返回 copied 的依据是写入依赖遵守约定并完成。传入一个虚假返回成功的适配器，这个控制器也无法证明系统实际发生了什么。因此，依赖注入便于测试控制流程，却不能替代真实浏览器验收。
4. 用可控 Promise 检查重复点击，而不是靠延时碰运气
将下面演示与上一段放在同一个 JavaScript 文件中执行。示例的写入函数只记录收到的合成文本，由测试代码决定何时完成，不会访问系统剪贴板。
(async () => {
let finish;
const submitted = [];
const action = createCopyAction(text => {
submitted.push(text);
return new Promise(resolve => {
finish = resolve; });
});
const first = action.copy("合成消息 A");
console.assert(action.isPending());
console.assert(await action.copy("合成消息 B") === "busy");
console.assert(submitted.length === 1);
finish();
console.assert(await first === "copied");
console.assert(!action.isPending());
console.assert(submitted[0] === "合成消息 A");
console.log(submitted);
})();
在 finish() 之前，第一个操作一直等待。第二次调用返回 busy，写入函数没有收到 B；第一个操作完成后，B 也不会自动补写。若用户仍希望复制 B，应再次明确发起复制。
配套验证还覆盖 Promise 拒绝、同步异常、失败后重试、空文本、缺少能力、原样保留空白和错误适配器等情况。连续 100 次等待期间的新调用都被拒绝为 busy，没有新增写入调用。这些检查是独立控制器的合成测试，没有测试产品客户端或浏览器的真实权限行为。
5. 接到浏览器时，仍要满足安全上下文和用户操作要求
真正接入时，应先确认环境支持所需能力。浏览器写入适配器可以使用 text => navigator.clipboard.writeText(text)，保持在原对象上调用方法。仅仅出现这个方法，并不保证本次写入会获准。
Clipboard API 受到安全上下文以及浏览器权限、用户激活等策略约束，具体要求存在浏览器差异，见 MDN 的安全说明。应从明确的复制点击发起操作，避免在调用写入前插入无关的网络等待；也不能把“任意一次 await 都必然导致失败”当成通用规律。
同一页面上若希望多个复制入口共享这里的等待规则，应共用一个控制器。给每个消息按钮各建一个实例，会得到多份独立的锁，无法阻止它们彼此同时调用写入。其他标签、应用或系统操作也不受这个局部控制器约束。
| 本例已经处理 | 接入层仍需验收 |
|---|---|
| 成功只在依赖完成后返回 | 真实浏览器权限、上下文与用户激活条件 |
| 同一控制器等待期间不重复写入 | 多个入口是否使用同一实例 |
| 异常后释放等待状态 | 按钮禁用、提示展示和组件销毁 |
busy 不进入队列 |
重试是否由用户明确发起 |
不应为了确认写入，就额外读取用户原有剪贴板内容。若需要验收实际粘贴结果，应在受控的合成文本场景下由明确操作完成，避免读取不相关内容。
当接口不可用或写入失败时，可以提供可选择的原文和手动复制提示。旧的 document.execCommand() 已被标记为弃用，见 MDN 文档，不宜把它当成保证成功的通用补救。
6. 超时提示不等于已经取消写入
本例没有设置超时，也没有实现取消。如果写入依赖一直未结束，pending 就一直保持为真。界面可以提示仍在等待，但不能仅因计时到了，就清锁并宣称底层写入已经取消。
否则，旧写入仍可能在新复制之后完成，让用户看到另一种顺序问题。计时器只说明等待了多久，不证明外部操作已经停止。需要恢复策略时，应结合真实接口能力与交互约定设计，而不是凭一个本地超时重置状态。
最后还要把结果绑定到原先发起复制的入口。等待期间消息列表可能变化，不能把 A 的完成结果显示成 B 已复制；组件卸载后的提示更新也需要接入层处理。本文没有实现 DOM 或框架组件，不把纯控制器测试当成页面验收。
复制反馈应准确表达本次已知事实：已发起、仍在等待、已完成或未完成。让提示跟随真实异步结果，再明确重复点击和恢复规则，才能避免把一次点击误报成一次成功复制。
本文由 AI 辅助整理，独立示例经过本地合成验证。产品背景只引用已整理的手机端复制操作资料；浏览器代码不代表原生 App 或产品内部实现，也未用于读取真实聊天内容或剪贴板数据。
