自动填充不工作：真正有效的修复方法
自动填充只会以少数几种可预测的方式失灵。实际上原因几乎从来不是 bug：而是保险库被锁、选错了提供方、桥接停止了连接、应用需要重启，或某个浏览器悄悄地开始从别处填充。
按可能性顺序走完下面这些。大约花五分钟，却能解决绝大多数情况。
修复 1：解锁保险库
这是遥遥领先的最常见原因，也是最容易漏掉的，因为应用 看起来 已安装并已启用。
- 扩展独立模式： 打开扩展弹窗并解锁。锁定的扩展无法解密任何东西，因此它什么也提供不了。
- 桌面桥接模式： 桌面应用必须已解锁。按设计，保险库锁定时桥接会拒绝工作。
- 移动端： 在聚焦到字段之前先打开应用并解锁。空闲时锁定意味着自动填充也会暂停。
如果建议只在你刚解锁后出现、随后又消失，答案就是这一条。
修复 2：检查系统提供方
更换密码管理器并不总会改变操作系统所提供的内容。
| 平台 | 检查位置 |
|---|---|
| Android | 设置 → 安全 → 自动填充服务 |
| iOS / iPadOS | 设置 → 密码 → AutoFill Passwords |
| macOS | 系统设置 → 通用 → 自动填充与密码 |
| Windows | 设置 → 账户 → 密码（凭据提供方） |
| Chrome | 设置 → 密码、passkeys 和自动填充 → 密码管理器 |
如果启用了两个管理器，操作系统会挑一个，另一个看起来就坏了。禁用你不要的那个，或者有意识地选择你要的那个 — 并在浏览器中确认同样的选择。
修复 3：重启目标应用或浏览器
更换凭据提供方并不总能在已经运行的进程中生效。这是常规现象，不是 bug：
- 移动端：强制退出你正要自动填充进去的那个应用，然后重新打开。
- 桌面端：完全退出浏览器（不只是关掉窗口）再重新打开。
- 如果问题出在浏览器上，就在改动其他任何东西之前先重启它 — 重新加载扩展往往能重新注册原生主机。
修复 4：重新连接桌面桥接
桌面自动填充是一次双向握手：应用注册一个原生消息主机，扩展通过本地套接字与它通信。当主机注册缺失或已过期时，它就会失败。
- 解锁 OpenKey 桌面应用。
- 打开 设置 → 安全 并切换自动填充 — 这会（重新）注册原生消息主机。
- 在 Chromium 系浏览器上，把你未打包扩展的 ID 写入对应平台的文件，然后再次切换自动填充，让清单重新生成：
| 平台 | 扩展 ID 文件 |
|---|---|
| Windows | %LOCALAPPDATA%\OpenKey\chrome_extension_id.txt |
| Linux | ~/.local/share/OpenKey/chrome_extension_id.txt |
- 在扩展中选择 使用桌面应用。
- 仅 macOS：确认 Python 3 在你的
PATH中 — 主机脚本需要它。
测试时也要确保保险库 仍处于解锁状态。桥接套接字只在解锁会话期间存在。
修复 5：检查是否存在竞争的管理器
Chrome 和 Edge 都自带内置密码存储，而且都很乐意继续自行填充。如果建议「消失」了、凭据却仍被填入，那就是内置管理器干的。
- 在浏览器设置中关闭已保存密码的自动登录，或
- 删除内置条目，让你的管理器接管这个登录项。
同样的冲突也会出现在 iCloud Keychain 与第三方 AutoFill 提供方之间，以及两个都申请了 <all_urls> 的扩展之间。
平台特定的原因
Chrome
扩展的网站访问权限：chrome://extensions → 你的扩展 → 详情 → 网站访问权限 → 在所有网站上，或者如果你偏好显式授权则选 点击时。自动填充需要页面访问权限才能检测字段。
如果另一个扩展占用了填充快捷键，可在 chrome://extensions/shortcuts 下重新映射。
Firefox
扩展第一次想在某个网站上填充时，Firefox 会请求权限，并且会默默拒绝某些「所有网站」的请求。在 about:addons → 权限 → 访问所有网站的数据 中检查扩展的权限。
Firefox 会自动使用 [email protected] 原生主机；在该平台上无需手动处理清单。
Safari
Safari 的自动填充与你的管理器是两个独立面板。在系统设置中启用管理器，然后在 Safari 中确认 密码 自动填充已打开。如果系统设置中的顺序发生了变化，Safari 也可能改用 另一个 凭据提供方来自动填充 — 要核对的是选择顺序，而不只是开关。
iOS 与 Android
- 按应用的状态： iOS 只在字段菜单中提供各种提供方，所以症状是「那个选项不在」，而不是「它填错了东西」。
- 权限提示： 系统在设置过程中会请求本地网络或生物识别权限。被拒绝的提示看起来就像管理器坏了。
- 填充前的生物识别： 如果你启用了填充前生物识别，那么每次填充现在都需要一次确认。这是正确行为，不是故障。
- 后台限制： Android 上激进的电池优化器会杀掉提供方进程，于是建议只在前台时出现。
用浏览器的自动填充审计来诊断
浏览器自带一个诊断功能，会报告它看到的每个字段、给出的每条建议，以及它被拒绝的原因。这把猜测变成了一个两分钟的过程。
在 Chrome 中，打开 DevTools → Application → Autofill，然后在页面上复现一次填充。你会得到被检测到的字段、给出的下拉项，以及任何被抑制的原因。当出问题的正是卡片或地址自动填充时，autofill.creditCards 和 autofill.profiles 也可以在 chrome://flags 中切换。
Firefox：about:debugging → 检查扩展，并在其控制台中查看填充时的错误。
如果你用的是 OpenKey
| 症状 | 检查 |
|---|---|
| 浏览器中没有建议 | 扩展已解锁，或桌面应用已解锁且已选择 使用桌面应用 |
| 「扩展无法与桌面应用通信」 | 原生主机注册、扩展 ID 文件、macOS 上的 Python 3 |
| Android 上什么都没有 | 在 Android 中已启用 设置 → 安全 → 自动填充，然后解锁应用 |
| iOS 上什么都没有 | 系统设置中已启用 AutoFill 提供方；重启目标应用 |
| Passkeys 回退到浏览器 | 选择 使用浏览器 时属于预期，或扩展保险库处于锁定状态 |
| 填充正常，保存失败 | 确认页面内的保存横幅没有被该页面拦截 |
扩展需要 <all_urls> 主机访问权限，才能检测字段、捕获登录项，并在任意网站上拦截 WebAuthn — 固定的允许列表无法覆盖开放网络。它解密的一切都留在你的设备或你自己的服务器上；页面内容不会发送给厂商云。
搜索数据说明
这是一个很大的查询簇，对任何撞上它的人都是个好兆头。互相比较自动填充故障排查的长尾词（Google Trends，全球范围，过去 12 个月）：
| 查询 | 簇内相对关注度 |
|---|---|
| autofill extension | 100 |
| autofill safari | 71 |
| autofill not working | 55 |
| password autofill chrome | 33 |
| chrome autofill not working | 2 |
「Autofill not working」达到通用词「autofill extension」一半以上的热度，意味着一个非常庞大的受众到达时已经坏掉了。具体在 Chrome 这个簇中，「google chrome autofill settings」以 100 占据最相关的查询位置，也是上升最快的，约同比增长 +70%，其中「chrome autofill extension」为 62，「chrome autofill not working」为 16。
这种分布指向一个具体的支持策略：以设置为主题的内容和一份值得信赖的排查清单，触达的人会比又一条功能公告更多。
Method: Google Trends，全球范围，过去 12 个月，2026 年九月提取。数字为归一化的相对关注度（0–100），而非搜索量。
30 秒版本
解锁保险库。确认选中了正确的系统提供方。重启应用或浏览器。在应用中重新切换一次自动填充，以重新注册原生主机。禁用任何竞争的管理器。如果仍然失败，打开浏览器的自动填充审计并读取拒绝原因 — 它会直接点名问题所在。
下一步
- 自动填充密码 — 设置指南
- 浏览器扩展 — 解锁模式与原生消息细节
- FAQ 与故障排查 — OpenKey 专属的修复方法
- 什么是 passkeys？ — 取代密码的那种凭据