Docker环境下wp-cli从wp-config.php读取错误数据库凭证引发连接失败

你遇到的数据库连接报错和网络连通性、Docker服务域名解析完全无关，核心原因是本地项目目录中存在历史遗留的wp-config.php文件。
WordPress官方镜像的初始化逻辑是：检测到/var/www/html路径下已有wp-config.php时，会直接跳过基于环境变量生成数据库配置的流程。因为你在wp服务里把本地当前目录全量挂载到了容器的/var/www/html路径下，wp-cli服务通过volumes_from挂载了完全相同的文件目录，所以wp-cli读取到的是这份旧文件里硬编码的、错误的数据库凭证（也就是日志里看到的username_here），而非你在docker-compose.yml中配置的root账号信息。

• 首先验证旧配置文件的内容，在本地项目根目录执行命令，提取文件内的数据库相关定义：

  grep -E "DB_USER|DB_PASSWORD|DB_HOST" ./wp-config.php
  

  执行后大概率能直接看到写死的define('DB_USER', 'username_here')这类配置，和你compose文件里定义的数据库凭证完全不匹配。
• 按以下流程操作修复：
  1. 停止所有运行中的容器：docker-compose down
  2. 把目录下残留的旧wp-config.php重命名备份：mv ./wp-config.php ./wp-config.php.bak
  3. 重新拉起所有服务：docker-compose up -d，等待WordPress镜像自动读取你配置的WORDPRESS_DB_*系列环境变量，生成全新的、和数据库凭证匹配的wp-config.php文件
  4. 验证wp-cli读取到的配置是否正确：

     docker-compose run --rm wpcli config list | grep DB_
     

     正常输出应该能看到DB_USER为root、DB_PASSWORD为你配置的数据库密码、DB_HOST为db，此时再执行docker-compose run --rm wpcli plugin list就不会出现访问被拒绝的报错。
• 额外优化与避坑提示：
  • 你在compose里配置的links: db:mysql属于Docker早期版本的老旧配置，当前Docker默认的自定义网络模式下，直接用服务名db就能完成内部域名解析，不需要额外添加links映射；wp-cli服务本身没有配置独立的WORDPRESS_DB_*环境变量，完全依赖共享目录下的wp-config.php连接数据库，只要这份配置和实际数据库凭证不匹配，wp-cli一定会同步报错。
  • 从报错日志里的容器内部IP段（192.168.32.5）可以判断，wp-cli容器已经能正常连通MySQL服务，被拒绝的原因纯粹是提交的用户名密码不匹配，不需要浪费时间排查数据库端口、防火墙、域名解析这类网络层面的问题。
  • 如果后续需要自定义wp-config.php的内容，不要直接往项目目录丢一份历史旧文件，要么手动把文件内的数据库相关定义改成和compose配置完全一致的内容，要么等官方镜像自动生成基础配置后再按需修改其他参数。

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