科技 · 实用指南
Docker 找不到凭据助手？先追踪配置、程序与调用者
先证明是哪份 Docker 配置选择了哪个 docker-credential-* 程序，以及同一用户、WSL、sudo 或服务进程能否运行它，再决定是否调整凭据存储。
这个错误点名的是一个程序，而不是已经损坏的密码：Docker 选择了 docker-credential-desktop、docker-credential-gcloud 等凭据助手，但启动 Docker 的进程无法执行它。删除 config.json 或把 credsStore 拼错可能暂时隐藏调用，却也可能关闭预期的安全存储。
保留原文件，确认 Docker 实际使用的配置和目标仓库条目，把选中的后缀转换为 docker-credential-<后缀>，再从同一用户、shell、sudo、WSL 或服务环境验证可见性。只修复已经证明损坏的边界。
冻结调用环境与有效配置
记录准确的失败命令和仓库，并记录 whoami、HOME、DOCKER_CONFIG、shell 或服务，以及是否经过 sudo 或 WSL。编辑前把有效的 config.json 复制到私密备份；不要把 auth、令牌或助手输出写入日志。
只检查选择助手的非秘密结构：先看目标仓库的 credHelpers，再看全局 credsStore。若设置了 DOCKER_CONFIG，或命令由 root、服务账户、另一 Windows/WSL 用户执行，就检查该调用者的文件。
把配置值映射到唯一程序
credHelpers 为目标仓库选择 gcloud 时，预期命令是 docker-credential-gcloud；credsStore 为 desktop 时，预期命令是 docker-credential-desktop。后缀是 Docker 实际执行的程序名，不是猜测的软件包名。
在同一调用环境中用 command -v、type -a 或平台等价命令定位该程序。若不存在，先区分过期的 Docker Desktop 桥接和主动配置的独立助手，再考虑安装、复制或建立链接。
区分 PATH 故障与助手内部故障
运行该助手文档支持且不会泄露秘密的能力检查，例如版本或列表命令。若官方提供 get 测试，把返回的 Secret 视为敏感信息，绝不要写入共享日志。
若 shell 无法启动助手，应修复安装或 PATH；若助手能启动却报告钥匙串、pass、gpg、Desktop 桥接或云端认证错误，就停止修改 Docker 配置，转而排查该助手。
只修复已证明的最小边界
仓库键或后缀错误时，只做经过复核的精确配置修改；官方助手缺失时，恢复该确切程序；用户、root、WSL 或服务不一致时，为真正运行 Docker 的进程对齐 HOME、DOCKER_CONFIG 与 PATH。
不要把 credsStore 改成 credStore 作为永久修复。后者不是有效存储键，Docker 会忽略它；只有在明确选择另一套文档化认证方案时，才删除或替换存储设置。
重试原路径并定义成功
重新启动同一 shell、服务、CI 任务或 WSL 发行版，再针对同一仓库运行原 Docker 命令。成功意味着助手执行错误消失、Docker 到达预期凭据存储，而且不是另一用户或配置碰巧提供结果。
若解析到意外副本、配置立即被重新生成，或错误只在 sudo/自动化中返回，就停止并重新比较调用者清单。在确认配置所有者和受支持助手前，不要删除已保存凭据。
