MySQL中root@localhost与root@127.0.0.1是两个独立账号,phpEnv默认用localhost连接但MySQL 8+常仅创建root@127.0.0.1,导致权限缺失而报Access denied;需检查用户表、补授权或改用127.0.0.1连接,并注意认证插件兼容性及配置文件陷阱。

不是密码错了,是 MySQL 根本没认出你这个 root 用户——root@localhost 和 root@127.0.0.1 在 MySQL 里是两个账号,权限可能一个有、一个空。
确认你连的是哪个 host(localhost 还是 127.0.0.1)
phpEnv 默认用 localhost 连接,但 MySQL 8+ 安装后往往只创建了 root@127.0.0.1,而没给 localhost 版本授权。结果就是:密码对、用户名对,照样报 Access denied for user 'root'@'localhost'。
- 进 MySQL 命令行(用已有高权限账号,比如
mysql -u root -p后输入已知密码),执行:SELECT User, Host FROM mysql.user; - 如果结果里没有
root行对应Host = 'localhost',就说明问题在这儿 - 临时解决:把 PHP 连接代码里的
'localhost'改成'127.0.0.1',绕过 socket 认证直连 TCP - 长期解决:补一个
root@localhost用户,或授权现有用户支持该 host
MySQL 8 默认认证插件不兼容老 PHP 驱动
phpEnv 通常捆绑较旧的 PHP(如 7.4 或 8.0),而 MySQL 8.0+ 默认用 caching_sha2_password 插件,mysqli/PDO 若未更新,会静默失败,错误还显示成“密码错”。
- 检查当前用户用的插件:
SELECT User, Host, plugin FROM mysql.user WHERE User = 'root'; - 如果
plugin是caching_sha2_password,就需降级兼容:ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password'; - 别忘了执行:
FLUSH PRIVILEGES; - 改完后重启 phpEnv 的 MySQL 服务(或整个 phpEnv 控制面板)
phpEnv 配置文件里藏了空格和引号陷阱
phpEnv 的数据库配置常写在 phpenv\config\php.ini 或项目里的 .env,肉眼难发现的空白字符会导致凭证传错。
使用tbot机器ID身份文件配合tsh CLI,通过Teleport访问控制SSH登录托管主机或执行远程命令。
立即学习“PHP免费学习笔记(深入)”;
- 打开配置文件,检查
DB_PASSWORD或类似项:前后有没有空格?比如DB_PASSWORD = " root "实际传的是带空格字符串 - 单引号和双引号在 .env 中行为不同:双引号内变量会被解析(如果用了
$),单引号原样保留;PHP 读取时若没 trim 就直接拼进连接串,必然失败 - 最稳妥做法:在 PHP 连接前加一句调试:
var_dump($host, $user, trim($password));,确认传进去的值和你认为的一致
root 用户根本没被授予 CREATE 权限(建库时报错的关键)
即使连上了,CREATE DATABASE 也会失败,报错仍是 Access denied —— 因为权限不够,不是连接问题。
- 连上 MySQL 后执行:
SHOW GRANTS FOR 'root'@'localhost'; - 输出里必须含
GRANT CREATE ON *.*或至少GRANT ALL PRIVILEGES ON *.*,否则建库操作会被拒绝 - 补权限命令:
GRANT CREATE ON *.* TO 'root'@'localhost'; FLUSH PRIVILEGES; - 注意:如果用的是 phpEnv 自带的低权限 demo 账号(比如
phpenv用户),它默认只有 test 库权限,不能建新库
最容易被忽略的点:phpEnv 启动时 MySQL 可能加载了多个配置文件(my.ini、my.cnf),其中某个文件里写了 skip-grant-tables,会导致权限系统失效,反而让某些操作看似成功、实则不可靠——建议检查所有 MySQL 配置路径下的 ini/cnf 文件,删掉任何跳过权限验证的配置。


















