Access denied for user 是权限问题而非密码错误,需确认用户名+主机名组合匹配、显式授权并执行FLUSH PRIVILEGES;PHP用localhost默认走socket,只认'user'@'localhost','user'@'%'无效。
看到 Access denied for user 'xxx'@'localhost' 或类似错误,第一反应别急着重置密码——MySQL 的用户权限是“用户名 + 主机名”联合认证的。'admin'@'localhost' 和 'admin'@'%' 是两个完全不同的账户,哪怕密码一样,权限也互不影响。
常见误操作:在 phpMyAdmin 或命令行用 CREATE USER 'user' IDENTIFIED BY 'pass'; 创建了用户,但没显式授权;或者用 root 本地登录后 GRANT 时写了 'user'@'127.0.0.1',而 PHP 用的是 localhost(二者在 MySQL 中解析机制不同)。
mysqli_connect('localhost', ...) 默认走 socket(对应 'user'@'localhost'),若改用 127.0.0.1 则走 TCP(对应 'user'@'127.0.0.1')SELECT User, Host FROM mysql.user WHERE User = 'your_user';
GRANT SELECT, INSERT ON your_db.* TO 'your_user'@'localhost'; FLUSH PRIVILEGES;
MySQL 的 'user'@'%' 允许从任意 IP 连接,但不包括 Unix socket 连接。当 PHP 使用 localhost 作为 host 参数时,mysqli 默认尝试 socket 连接(绕过 TCP/IP 栈),此时只认 'user'@'localhost','user'@'%' 完全无效。
验证方式:在命令行运行 mysql -u your_user -p -h localhost(会失败),再试 mysql -u your_user -p -h 127.0.0.1(可能成功)——这就是 host 解析差异。
'user'@'%' 起作用,PHP 必须用 mysqli_connect('127.0.0.1', ...) 或 mysqli_connect('your-server-ip', ...)
localhost,就老老实实创建并授权 'user'@'localhost'
host.docker.internal,不是 localhost
MySQL 5.7+ 大部分情况下 GRANT 会自动重载权限表,但存在例外:比如对已存在的用户修改主机名、或在某些复制/集群配置下,权限缓存未刷新会导致新授权不生效。这不是 bug,是设计行为。
最稳妥做法:每次 GRANT 或 CREATE USER 后,立刻跟一句 FLUSH PRIVILEGES;。它强制重载权限表,确保内存中权限状态与磁盘一致。
FLUSH PRIVILEGES; 是 SQL 语句,需在 MySQL 客户端中执行,不是 shell 命令mysqli_query($conn, 'FLUSH PRIVILEGES'); —— 普通用户无此权限,必须用 root 或有 RELOAD 权限的账号执行默认情况下 mysqli_connect() 失败只返回 false,错误信息藏在 mysqli_connect_error() 里,但很多人忘了查。更隐蔽的问题是:即使连接成功,后续查询因权限不足(比如没 SELECT 权)报错,错误信息也不直观。
启用报告模式可让 mysqli 在出错时直接抛出异常,便于定位:
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
放在 mysqli_connect() 前即可。这样权限不足、表不存在、字段无访问权等

mysqli_sql_exception,而不是静默失败或返回 false。
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION),但 mysqli 不互通权限体系本身不复杂,但 user@host 组合、socket/TCP 差异、权限缓存时机这三点叠在一起,就很容易卡住。调不通时,先用 MySQL 客户端模拟 PHP 的连接参数(host、user、password、database),再逐项核对 SELECT User,Host FROM mysql.user 输出——比反复改代码快得多。