Docker PostgreSQL容器凭证无效：一个可连一个失败问题排查

以下是几个最可能导致该问题的原因及对应的排查方向：

• 旧数据卷残留冲突
  如果之前启动过同名的db容器，很可能挂载了未清理的旧数据卷——PostgreSQL的用户凭证是在首次初始化时写入数据卷的，后续启动会直接复用卷里的旧数据，哪怕你修改了docker-compose里的环境变量。而test-db是全新容器，用的是新数据卷，所以能正常连接。
  排查：执行docker volume ls找到对应db服务的数据卷，用docker volume rm [卷名]删除后，重新启动db容器。或者直接用docker-compose down -v清理所有关联卷（注意备份重要数据）。

• 连接参数混淆或端口占用
  虽然配置里端口映射不同，但你连接db时可能误填了test-db的端口；或者本地已有其他PostgreSQL服务占用了db的映射端口，导致你实际连接的是本地数据库而非容器内的，自然凭证不匹配。
  排查：用docker ps确认db的端口映射是否符合配置，连接时严格指定对应端口（比如psql -h localhost -p 5432 -U myuser）；用netstat -tulpn（Linux）或netstat -ano（Windows）检查端口是否被其他进程占用。

• 环境变量配置隐性错误
  仔细对比db和test-db的docker-compose配置，可能db的POSTGRES_PASSWORD、POSTGRES_USER存在隐性错误——比如多了空格、大小写不一致，或者引用.env文件时变量名写错，导致容器初始化时用了默认凭证而非你配置的。
  排查：进入db容器执行env命令，查看实际生效的环境变量，和docker-compose配置对比；也可以直接查看容器启动日志的初始化部分（哪怕日志无报错，初始化阶段的输出可能藏着凭证设置的细节）。

• 数据卷权限异常导致初始化失败
  部分情况下，db容器挂载的数据卷权限不符合PostgreSQL的要求（比如容器内/var/lib/postgresql/data目录不是postgres用户权限），导致初始化脚本无法写入配置的凭证，容器只能用默认的空密码启动，但你用配置的密码连接就会失败。
  排查：进入db容器执行ls -l /var/lib/postgresql/data检查权限；尝试用默认用户postgres、空密码连接，如果能成功，说明初始化时环境变量未生效，需要修复数据卷权限或重新初始化。

内容的提问来源于stack exchange，提问作者Johnyb