如何在谷歌浏览器中彻底关闭自动保存密码弹窗？
功能定位：为什么弹窗总出现
谷歌浏览器的「自动保存密码弹窗」是增强型密码管理器的一部分，目的是把账号密文写入本地 SQLite 并在 Google 账号加密同步。当检测到表单内含 type="password" 的输入框且提交事件触发时，Blink 主进程会立即拉起一条模态条（桌面称「Save password?」、移动端称「要保存密码吗？」）。若用户连续 3 次忽略，该域名会被临时加入「静默黑名单」，但重装或 90 天无记录后又会复活。因此「彻底关闭」需要把用户层、系统层、企业策略三条通路全部关掉，否则只是「暂时看不见」。
桌面端最短路径：chrome://settings 内一键关闭
以 Windows 13 / macOS 14 上 Chrome 132 为例，地址栏输入 chrome://settings/passwords 回车，在「提供保存密码」开关直接关闭即可。该选项实时写入 Preferences JSON，无需重启。若你同时登录了 Google 账号，关闭状态会同步到所有已登录设备，但同步延迟经验性观察在数十秒至数分钟之间，可手动触发「设置-同步-立即同步」加速。
回退方案
再次进入同一页面把开关重新打开即可；历史已保存的凭据不会因此删除，只是浏览器不再询问「是否新增」。若你希望把旧记录也清空，可在同一页面点「查看和管理密码」→ 右上角「⋮」→ 全部删除。
Android 端路径差异：被系统级「自动填充」接管
在 Android 14+ 上，Chrome 132 把保存弹窗拆成两条：浏览器自身弹窗 + Android 系统「凭据管理器」浮层。仅关闭 Chrome 的「提供保存密码」只能去掉第一条；若系统层 Google 自动填充仍开启，用户依旧会在键盘上方看到「保存密码？」气泡。因此需要两步：
- Chrome App → 右上角「⋮」→ 设置 → 密码管理器 → 关闭「提供保存密码」。
- 系统设置 → 密码与账号 → 自动填充服务 → 选择「无」或第三方密码器（如 Bitwarden）。
经验性观察：部分国产 ROM 把「自动填充」入口放在「设置-更多连接」里，路径名称可能叫「智能密码本」，关闭逻辑相同。
iOS 端：需同时处理「钥匙串」与 Chrome 内部开关
iOS 17 以后，Apple 允许第三方浏览器调用系统钥匙串。Chrome 132 默认勾选「与 iCloud 钥匙串同步」。关闭弹窗必须：
- Chrome → ... → 设置 → 密码 → 关闭「保存密码」。
- iOS 设置 → 密码 → 密码选项 → 关闭「自动填充密码」或把 Chrome 从允许列表中移除。
否则系统会在键盘上方出现「是否存储到钥匙串」的二次弹窗，看起来像是 Chrome 的，其实走的是 iOS 统一接口。
企业环境：用 Chrome 策略模板一次性下发
对于 Windows 域控或 Chrome Browser Cloud Management（CBCM）托管设备，管理员可在 Google 提供的 ADMX 模板里把 PasswordManagerEnabled 设为 Disabled。路径：组策略编辑器 → 计算机配置 → 管理模板 → Google → Google Chrome → 密码管理器 → 停用密码管理器。生效后用户侧界面呈灰显状态，无法自行开启，且 chrome://policy 页面可看到「PasswordManagerEnabled = false」。
边界与副作用
该策略会同时禁用通行密钥（Passkey）本地生物识别填充，若公司正在推行无密码登录，需改用第三方 FIDO2 证书或 YubiKey。
隐身模式例外：策略无法继承
隐身窗口默认不保存密码，因此也不会弹窗；但如果用户手动在地址栏侧板「钥匙图标」里点「保存」，Chrome 会立即把该条写入普通模式的本地数据库，下次正常访问同一站点仍会提示更新。经验性观察：部分用户误以为「隐身=无弹窗」，其实只在会话内不提示，行为与主数据库仍互通。
第三方扩展能否拦截？Manifest V3 下的现实
Chrome 132 已全面停用 Manifest V2，content script 无法直接拦截浏览器级弹窗。GitHub 上有示例项目尝试在 submit 事件里注入 preventDefault() 然后手动清空表单，但会导致页面本身 AJAX 登录失败，兼容性差。结论：扩展只能「隐藏」而无法「阻止」写入，企业仍需靠策略开关。
验证是否彻底关闭：3 步可复现检测
- 准备一套从未登录过的测试站点（例如临时搭建的 WordPress 或 GitHub 私有仓库）。
- 在完全关闭密码保存后，手动输入任意账号密码并提交。
- 观察：地址栏下方不得出现「Save password?」横条；Android/iOS 键盘上方不得出现「保存到 Google」或「保存到钥匙串」气泡；
chrome://settings/passwords里不得新增条目。
若 3 步全部通过，可判定已彻底关闭；若仍出现，则检查是否遗漏系统级自动填充或其他设备同步回写。
常见失败分支与排查表
| 现象 | 最可能原因 | 验证动作 |
|---|---|---|
| 关闭后第二天又弹 | 同步把另一台设备的开启状态拉回 | 看 chrome://sync-internals 的「Password」节点是否被远程更新 |
| Android 仍出现气泡 | 系统级自动填充未关 | 系统设置搜索「自动填充」→ 关闭 Google 服务 |
| 公司电脑灰显无法改 | 组策略已锁定 | 地址栏输入 chrome://policy 查看 PasswordManagerEnabled |
不适用场景清单
- 需要通行密钥（Passkey）做无密码登录的站点，关闭后只能回退到传统密码。
- 多人共用一台设备且依赖 Chrome 同步密码，关闭后其他家庭成员无法自动填充。
- 公司强制要求审计密码强度，关闭后需额外采购第三方密码管理器（如 1Password Business）以满足合规。
最佳实践 5 条速查表
- 个人用户：优先用 chrome://settings/passwords 开关，30 秒可逆。
- 家庭共享：为儿童账号单独建立受监管用户，策略只对孩子配置，成人保留密码管理器。
- 企业部署：一律用 CBCM 或 ADMX 模板统一关闭，避免员工自行开启导致审计缺口。
- 开发测试：用隐身窗口 + 临时用户数据目录启动
--user-data-dir=/tmp/test，可 100% 回避弹窗。 - 合规场景：关闭后若仍需保存密码，选用通过 SOC2 的第三方管理器，并关闭浏览器级同步。
提示：关闭弹窗不会删除已存密码，也不会影响自动填充旧记录；如需一并清除，请在同一页面手动删除或使用 chrome://settings/passwords/check 批量清理弱密码。
FAQ：常见疑问与官方说法
关闭后还能用通行密钥吗？
不能。Chrome 把通行密钥托管在同级数据库，策略级关闭会一并停用。需改用系统级或硬件 FIDO2 认证器。
为何我设置了 ADMX 仍有人能保存？
检查是否启用了「用户配置」而非「计算机配置」；用户配置可被本地 Preferences 覆盖。建议统一用计算机配置并启用「强制」。
Android 关闭后其他浏览器会受影响吗？
不会。系统级自动填充对 Edge、Firefox、三星浏览器同样生效；关闭 Google 服务后，可单独为其他浏览器选择不同自动填充器。
总结与下一步行动
谷歌浏览器的自动保存密码弹窗看似只是 UI 层面的打扰，实则涉及用户数据、企业合规与多平台自动填充三条链路。个人用户 30 秒即可在设置内关闭；企业则应用策略模板一次性下发，并评估通行密钥停用后的替代方案。完成关闭后，用测试站点复现验证，确保系统级自动填充、同步回写、隐身例外三条通路都已失效，才算真正「彻底」。
下一步，如果你是 IT 管理员，可把本文排查表加入内部 Wiki，并每季度复查 chrome://policy 是否被用户通过注册表回改；如果你是个人用户，建议每半年在 chrome://settings/passwords/check 跑一次弱密码扫描，即使不再新增，也要确保旧记录安全。最后，别忘了把这篇路径收藏到书签，Chrome 133 若再次调整菜单名称，你仍能按图索骥。
