navigator.clipboard.readText() 必须由用户手势触发且页面聚焦，无法自动读取；优化方案是绑定到点击粘贴按钮、输入框聚焦或paste事件，配合权限检测、内容清洗、错误降级与防抖处理。
直接调用 navigator.clipboard.readText() 无法“自动”读取剪贴板内容，浏览器出于安全限制，该 API 必须在**用户手势触发的上下文**（如 click、tap、keydown）中才能调用，且需页面处于**聚焦状态**。所谓“自动读取验证码”实际是指：当用户复制了验证码（例如从短信、邮件或弹窗中），在表单输入框获得焦点或点击粘贴按钮时，立即尝试读取并填充，而非真正后台静默监听。
必须由用户操作触发
浏览器禁止页面在无用户交互时访问剪贴板，这是硬性策略，无法绕过。因此“优化填充体验”的关键在于把读取动作绑定到明确的用户行为上：
- 点击“粘贴验证码”按钮时调用
readText() - 验证码输入框获得焦点后，短按 Ctrl+V 或 Cmd+V（但不拦截默认粘贴，而是作为补充尝试）
- 监听
paste事件，在事件回调中调用readText()并校验内容是否为 4–6 位数字/字母（增强容错）
需处理权限与降级逻辑
不是所有环境都支持 navigator.clipboard（如旧版 Safari、部分 WebView）。应先检测能力，并准备 fallback：
- 用
if ('clipboard' in navigator)判断支持性 - 若不支持，回退到传统
document.execCommand('paste')（已废弃但部分环境仍可用）或提示用户手动粘贴 - 首次调用前可能触发权限请求（Chrome/Edge 在部分版本中会弹出“允许访问剪贴板”提示），需捕获拒绝错误（
NotAllowedError）并友好提示
读取后需做内容清洗与校验
剪贴板内容不可控——可能是带空格的字符串、换行符、前后空格、甚至完整句子。直接填入可能导致验证失败：
- 用
.trim().replace(/[^0-9a-zA-Z]/g, '')清洗非字符数字内容 - 限制长度（如只取前 6 位），避免超长码截断错误
- 填充前检查输入框是否为空且未失焦，防止误覆盖用户已输内容
避免频繁报错干扰体验
读取失败很常见（权限拒绝、剪贴板为空、跨域 iframe 等），不要每次失败都弹 Toast。建议：
- 仅在用户主动点击“粘贴”按钮后失败时提示“请手动输入或检查是否已复制验证码”
- 在
paste事件中读取失败时，不做任何提示——默认粘贴行为仍有效，用户无感知 - 添加防抖：同一输入框 1 秒内不重复调用
readText()，防止快速连点触发多次失败
不复杂但容易忽略。核心是把“读剪贴板”当作一次受控的、有上下文的用户辅助操作，而不是后台自动化流程。
