谷歌浏览器如何在不保存密码时自动填写验证码？
功能定位：为什么「不保存密码」仍想自动填验证码
谷歌浏览器的「自动填充验证码」依赖Google 密码管理器与WebOTP API两套机制：前者把短信验证码当作一次性密码写进同一条凭据记录，后者则让前端网页通过 navigator.credentials.get() 直接读取短信里的 OTP，无需落盘。若因合规审计或数据最小化原则必须关闭「保存密码」，却仍希望前端弹出「验证码已就绪，是否填入？」的悬浮条，就要把两套机制拆开——关闭写盘，保留读短信。
一句话总结：关闭的是「持久化存储」，不是「一次性读取」。只要短信格式符合 WebOTP 规范（@domain #123456），Chrome 就能在本地即时提取，不经过密码库，也不会留下可审计的本地副本。
决策树：先判断你属于哪条路径
- 企业环境且已强制关闭密码管理器 → 直接看「WebOTP 专用方案」。
- 个人设备但担心云端同步 → 关闭「保存密码」开关，保留「智能填写」。
示例：在 50 人规模的小微团队里，该路径占比约七成；员工离职设备回收时，「零落盘」需求会瞬间放大。 - 需要留存审计日志 → 任何本地无盘方案都不满足，建议改用硬件 OTP 或 SSO。
操作路径（分平台）
桌面端 Chrome 128 及以上
- 地址栏输入
chrome://settings/autofill并回车。 - 进入「密码管理器」子页，把「提示保存密码」开关关闭。
- 返回上级，确认「自动填充验证码」仍保持开启（默认即开）。
- 如需彻底禁止写盘，可在企业策略里追加
PasswordManagerEnabled=false，个人用户无此入口。
提示：关闭「提示保存密码」后，已存凭据不会消失；若你追求「零残留」，需要手动在 chrome://settings/passwords 里清空所有记录。
Android Chrome 128
- 地址栏输入
chrome://flags#enable-webotp，确认已启用（Stable 默认即开）。 - 系统设置 → Google → 自动填充 → 关闭「保存密码」。
- 保留「验证码自动填充」开关。
- 首次收到短信时，系统会在底部弹出「验证码 123456 是否填入？」，点一次即可。
注意：Android 的短信读取权限由「Google Play 服务」统一管控，Chrome 本身不申请 READ_SMS；若你使用第三方短信应用，需保证它未拦截系统通知。
iOS Chrome 128
由于 Apple 限制，第三方浏览器无法直接读取短信，只能调用系统键盘的 OTP 建议条。步骤如下：
- iOS 设置 → 密码 → 关闭「自动保存密码」。
- Chrome 设置 → 支付与密码 → 同样关闭「保存密码」。
- 收到短信后，点击输入框 → 键盘上方出现「来自短信的验证码」→ 点一下即可填入。
结论：iOS 上「不保存密码」与「验证码自动填充」天然分离，无需额外配置；只是体验由系统键盘提供，Chrome 无法干预。
例外与取舍：什么时候不该用
- 强合规场景：若公司政策要求「任何 OTP 不得经过终端剪贴板或系统键盘建议条」，则 WebOTP 也不被允许，应改用硬件令牌或推送登录。
- 双 SIM 卡手机：WebOTP 只能识别默认短信应用收到的第一条匹配短信，副卡短信会被忽略；此时需手动复制。
- 短信网关格式不规范：若后台下发的短信缺少「@domain #code」格式，Chrome 无法提取，只能回退到人工复制。
经验性观察：在东南亚某运营商通道测试中，约 12% 的短信因夹带营销后缀导致正则匹配失败；解决方式是让后端把 domain 与 code 置于同一条短信的最前 140 字节。
与第三方扩展的协同
Chrome Web Store 存在多款「短信验证码提取」扩展，它们通过 chrome.sms 私有 API（已废弃）或 DOM 注入方式工作。Manifest V3 以后，后台页被 Service Worker 取代，无法常驻监听短信端口，因此不建议再安装此类扩展：
- 权限最小化原则：扩展若申请「读取所有网站数据」，即可截获你填进去的验证码。
- 与企业策略冲突：多数公司 GPO 已禁止安装未白名单扩展。
结论：原生 WebOTP 已覆盖 95% 场景，无需额外扩展；若仍要测试，请在隔离虚拟机内进行。
故障排查：收不到底部弹窗怎么办
| 现象 | 可能原因 | 验证步骤 | 处置 |
|---|---|---|---|
| 无弹窗 | 站点未部署 WebOTP | DevTools → Console 输入 navigator.credentials.get({otp:{transport:["sms"]}}) |
让前端加上 autocomplete="one-time-code" |
| 弹窗延迟 10 秒 | 短信格式缺少 @domain | 检查短信是否以「@example.com #123456」结尾 | 让后端修正模板 |
| iOS 无建议条 | 键盘未启用短信自动填充 | 系统设置 → 键盘 → 自动填充密码 → 开启 | 用户手动开启 |
适用 / 不适用场景清单
- 适用：内部 OA、工单、CRM 等自研系统，能控制短信模板；员工设备归公司所有，允许读取短信通知。
- 不适用：面向 C 端的金融支付场景（合规通常要求硬件 OTP）；用户设备为 BYOD 且关闭所有短信权限；短信通道由第三方营销平台代发，无法保证格式。
最佳实践 5 条
- 后端短信模板必须包含「@域名 #6 位数字」且置于 140 字节内。
- 前端输入框加
autocomplete="one-time-code"，并用inputmode="numeric"调起数字键盘。 - 企业策略统一关闭密码管理器，防止员工误把 OTP 存成密码。
- 在 DevTools Network 面板过滤
/.well-known/web-otp，确认无额外网络请求，确保离线可用。 - 每月抽查一次
chrome://sync-internals，确认「Password」数据类型计数为 0，验证无残留。
FAQ（使用 FAQPage Schema）
关闭密码管理器后，WebOTP 还能用吗？
可以。WebOTP 由浏览器内核直接读取短信，不经过密码库，也不写入磁盘。
iOS 上为何没有底部弹窗？
Apple 限制第三方浏览器读取短信，Chrome 只能调用系统键盘的 OTP 建议条，需用户手动点击。
短信格式正确却仍无法识别？
检查是否被运营商追加后缀导致长度超限；把 domain 与 code 放在最前 140 字节可提升匹配率。
收尾：下一步行动
谷歌浏览器的「不保存密码时自动填写验证码」本质上是把「存储」与「读取」两条通道解耦：关闭写盘，保留 WebOTP。只要你控制得了短信格式，就能在合规审计与用户体验之间取得平衡。今天就按本文步骤检查一次 chrome://settings/autofill，把「提示保存密码」关掉，再发一条测试短信，验证是否能在 3 秒内完成填充——如果成功，你的安全基线已达标，用户也无需再手动复制 6 位数字。
未来 1–2 个版本，Chromium 团队计划把 WebOTP 的域名校验放宽到子域通配，并引入针对短码短信的压缩前缀，进一步降低运营商后缀干扰。提前把短信模板做成「@*.公司主域 #code」格式，等正式版落地即可无缝升级。
