标准 Docker Compose 并没有名为 registry_config 的配置方法，私有仓库认证通常通过 docker login 登录到本地 Docker 客户端来完成，Compose 会直接复用这份认证信息。
先说结论：不要寻找不存在的 registry_config 字段，直接在运行 Compose 前使用 docker login 完成认证是最标准且兼容性最好的方案。
- 适合：所有基于 Docker Engine 的 Compose 环境（本地开发、CI/CD 流水线）。
- 先准备：确保拥有私有仓库的账号、密码或访问令牌。
- 验收：执行
docker compose pull确认镜像能正常下载且无认证报错。
命令速用版
在运行 docker compose up 之前，先在终端执行以下命令完成登录：
docker login your-registry.com
# 输入用户名和密码后
docker compose up -d如果是 CI/CD 环境，通常通过环境变量传入密码：
echo "$REGISTRY_PASSWORD" | docker login your-registry.com -u "$REGISTRY_USERNAME" `--password-stdin`为什么会这样
Docker Compose 本身不负责存储或管理镜像仓库的凭证，它依赖底层 Docker Engine 或 Docker Client 的配置。当你执行 docker login 时，凭证会被加密保存在本地的 ~/.docker/config.json 文件中。Compose 在拉取镜像时，会调用 Docker API，Docker 守护进程会自动读取这份配置文件中的认证信息。因此，在 Compose 文件中配置类似 registry_config 的字段既不符合规范，也没有必要。
分步处理
1. 确认仓库地址
检查 docker-compose.yml 中 image 字段，确认私有仓库的域名（例如 registry.example.com）。
2. 执行登录命令
在运行 Compose 的同一台机器上执行登录。如果是本地开发，直接交互式输入密码；如果是脚本，建议使用 `--password-stdin` 避免密码泄露。
3. 检查配置文件
登录成功后，可以查看 ~/.docker/config.json，确认 auths 字段下是否有对应仓库的条目。这一步能确认凭证是否真的写入。
4. 运行 Compose
执行 docker compose up -d。如果之前拉取过旧镜像，建议先运行 docker compose pull 强制刷新认证。
怎么验证是否生效
1. 观察拉取日志
运行 docker compose pull 时，观察终端输出。如果出现 pull access denied 或 unauthorized，说明认证未生效。
2. 检查本地镜像
执行 docker images，确认私有仓库的镜像已经存在于本地列表中，且标签正确。
3. 容器状态
执行 docker compose ps，确认容器状态为 Up 而不是 Created 或不断重启（因拉取失败导致）。
常见坑
1. 配置文件路径不一致
如果在 CI/CD 或特定用户环境下运行，确保 DOCKER_CONFIG 环境变量指向正确的配置文件目录，否则 Docker 可能读取不到登录信息。
2. 密码包含特殊字符
某些 Shell 会对特殊字符进行转义，导致密码传递错误。建议使用 `--password-stdin` 方式传入密码。
3. 混淆 Daemon 配置
不要将仓库认证配置到 /etc/docker/daemon.json 中，该文件主要用于配置 insecure-registries 或镜像加速，不存储用户凭证。
参考来源
- Docker Documentation -
docker loginreference: https://docs.docker.com/engine/reference/commandline/login/ - Compose Specification - Service image definition: https://compose-spec.io/
- Docker Documentation - Store credentials in Docker Config: https://docs.docker.com/engine/reference/commandline/cli/#configuration-files