PostgreSQL Docker容器间通信异常 密码认证失败问题咨询

POSTGRES_PASSWORD 环境变量仅在Postgres容器首次初始化空数据目录时生效，不会在容器后续重启时覆盖已存在的用户密码。
你现在遇到认证失败，核心原因是之前启动db容器时已经生成过带旧密码的postgres数据卷（多数是未手动删除的匿名卷），本次启动时镜像检测到数据目录已存在，直接跳过了密码初始化步骤，你在yml里新写的POSTGRES_PASSWORD: example根本没有被加载，result服务拿配置里的密码去连存在旧密码的数据库，自然会触发md5认证失败。

这个方案没有任何生产可用性，安全性为0。
trust认证模式的逻辑是：只要客户端能连通数据库的TCP端口，不需要提供任何有效密码，就能直接以匹配的用户名登录，甚至直接拿postgres超级用户权限。等于完全绕过了数据库层面的所有身份校验，只要能访问到数据库端口的人都可以任意读写、删除全量数据，仅适合本地临时做1分钟不到的功能验证，绝对不能作为长期解决方案。

• 先清理残留的旧数据卷：执行docker-compose down -v 命令停止当前服务栈并删除关联的所有数据卷（注意：如果旧数据卷里有需要留存的业务数据，先手动备份再执行该命令，否则数据会被永久删除）。清理完成后重新执行docker-compose up，此时db容器会首次初始化空数据目录，你配置的POSTGRES_PASSWORD=example会被正确写入，认证即可恢复正常。
• 不要在docker-compose.yml里明文硬编码数据库密码，将敏感值存入同目录下的.env文件，或者使用Docker Secrets进行密钥管理，避免密码随配置文件泄露。
• 业务连接不要直接使用postgres超级用户：在db服务的环境变量里额外配置POSTGRES_USER、POSTGRES_DB为业务专属的账号和库名，给result服务配置对应普通账号的连接串，遵循最小权限原则，避免超级账号泄露带来的全库风险。
• 额外提示：你当前使用的postgres:9.4镜像已经停止官方维护超过8年，存在大量未修复的安全漏洞和兼容性问题，仅适合本地测试使用，生产环境请替换为仍在支持周期内的Postgres版本。

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