必须用 await 或 .then() 等待 uni.setClipboardData Promise 完成后再执行下一步，不可同步调用后立即执行 nextStep；需封装跨平台 Promise 函数统一处理异常与平台差异，并加防抖状态控制，H5 环境须确保复制在用户手势同步上下文中触发。
复制成功后怎么触发下一步逻辑？别用 success 回调，要 await
uni.setClipboardData 是 Promise 化 API，但很多人误以为它像老式 wx.setClipboardData 那样支持 success 回调。实际在 uni-app 中，uni.setClipboardData 返回 Promise，必须用 await 或 .then() 捕获完成时机，否则“下一步操作”会立刻执行，根本等不到复制真正完成。
常见错误是写成：uni.setClipboardData({ data: text }); nextStep();——这会导致 nextStep() 在剪贴板还没写入时就跑了，尤其在 App 端有明显延迟感。
- 必须用
await uni.setClipboardData({ data: text })，再写后续逻辑 - 如果用
.then()，确保nextStep()放在.then()里，不是写在后面一行 - H5 降级路径（
navigator.clipboard.writeText）同样要 await，不能混用同步写法
跨平台复制后统一走下一步，怎么组织代码结构？
不同平台的复制实现不同，但“复制成功后执行下一步”这个语义必须一致。硬编码多个 if-else 容易漏掉异常分支，推荐封装一个返回 Promise 的函数，把平台判断和错误处理收口。
关键点不是“怎么复制”，而是“怎么让所有平台都可靠地 resolve 或 reject”。比如 H5 下 navigator.clipboard.writeText 在非 HTTPS 或无用户手势时直接抛错，而 document.execCommand('copy') 可能静默失败——这些都要兜住。
- 用
uni.getSystemInfoSync().platform判断平台，比写死process.env.UNI_PLATFORM === 'h5'更可靠 - 所有分支最后都应
return Promise.resolve()或显式throw，避免部分路径不返回 Promise - 下一步操作（如跳转、关闭弹窗、更新 UI 状态）统一放在主函数的
try块末尾，不要分散在各平台分支里
为什么有时 nextStep() 执行了，但剪贴板内容还是旧的？
这不是代码 bug，而是平台行为差异导致的“感知延迟”。尤其在 Android App 端，uni.setClipboardData 调用后，系统粘贴板服务可能需要几十毫秒才真正落盘。如果 nextStep() 是立即读取剪贴板（比如调用 uni.getClipboardData），大概率拿到的是上一次的内容。
- 不要在复制后立刻调用
uni.getClipboardData验证——它不可靠，且小程序/H5 实现不一致 - 若业务强依赖“确认写入成功”，建议加
await new Promise(r => setTimeout(r, 100))微延时（仅限 App 端必要场景） - 更合理的做法是：信任 API 的 resolve，把“下一步”设计为不依赖即时读取剪贴板的操作（如跳转页、提示文案、按钮状态重置）
连续点击触发多次复制 + 多次 nextStep 怎么防抖？
用户手快连点，会导致复制逻辑重复执行，nextStep() 也被反复调用——比如弹两次 toast、跳两次页、发两次请求。这不是 Promise 本身的问题，而是缺少状态控制。
- 加一个
isCopying标志位，点击前设为true，resolve 后设回false，期间忽略点击 - 按钮绑定
@click="handleCopy"，而不是直接@click="copy(text)"，把控制权收在方法内 - 注意：标志位要设在组件 data / reactive 数据中，不能用局部变量，否则无法响应式拦截后续点击
navigator.clipboard.writeText 的安全限制——它只在用户手势触发的同步上下文中有效。如果你把复制逻辑包在 setTimeout、Promise.then 或异步事件回调里，即使页面是 HTTPS，也会直接报 NotAllowedError。这意味着“下一步操作”如果改变了触发上下文，就可能让整个链路失效。 
