mysql错误1045本质是用户身份元组'xxx'@'yyy'未匹配权限表记录，而非密码错误；需严格核对user与host字段是否完全一致，并区分localhost（socket）与ip（tcp）连接路径。
Access denied for user 'xxx'@'yyy' 是权限匹配失败，不是密码输错了
这个错误根本不是“密码不对”，而是 MySQL 在权限表里没找到 'xxx'@'yyy' 这条记录。重点看错误信息末尾的 @'yyy' —— 它是 MySQL 实际认定的客户端来源，可能是 localhost、127.0.0.1、192.168.1.100 或 %。你代码里写的是 localhost，但 MySQL 可能只授权了 'xxx'@'127.0.0.1'，这就完全不匹配。
常见误判点：
- 以为改对密码就万事大吉，其实用户根本不存在于该 host 下
- 在 PHP 里用
mysqli_connect('localhost', ...)，却只创建了'user'@'127.0.0.1'—— 两者在权限系统中互不认 - 用 Docker 或云服务时，
localhost指的是容器内部，不是宿主机，host 必须填host.docker.internal或服务名
用 mysql 命令行直连验证，绕过 PHP 干扰
别在 PHP 里反复试错。直接在服务器（或容器内）执行命令，最准：
mysql -u your_user -p -h 127.0.0.1 -P 3306
注意必须加 -h 127.0.0.1，否则默认走 socket（等价于 @'localhost'），和 PHP 里的 'localhost' 行为一致，但可能不是你想要的路径。
成功登录后立刻执行：
SELECT USER(), CURRENT_USER();
USER() 显示你声明的身份，CURRENT_USER() 才是你真正被匹配到的权限记录。如果两者不同，比如 USER() 返回 'myapp'@'192.168.1.50' 而 CURRENT_USER() 是 'myapp'@'%'，说明有更宽泛的 host 规则覆盖了它；如果后者是 ''@''，说明认证彻底失败。
CREATE USER 和 GRANT 必须严格匹配 host 字段
MySQL 的权限是按 'user'@'host' 二元组存储的，漏掉 host 就等于授权给错地方。
正确操作顺序：
- 先明确你要从哪连：本地 CLI？PHP-FPM 容器？远程服务器？得到真实 host 值（如
'127.0.0.1'、'%'、'172.20.0.3'） - 用完整 host 创建用户：
CREATE USER 'myapp'@'127.0.0.1' IDENTIFIED BY 'real_password'; - 授予权限时 host 必须一致：
GRANT SELECT, INSERT ON mydb.* TO 'myapp'@'127.0.0.1'; - 最后刷新：
FLUSH PRIVILEGES;
别写 CREATE USER 'myapp' IDENTIFIED BY 'pwd'; —— 这会默认生成 'myapp'@'%'，但若已有 'myapp'@'localhost'，优先级更高，反而导致混乱。
PHP 连接时 host 写法决定走 socket 还是 TCP
mysqli_connect('localhost', ...) 和 mysqli_connect('127.0.0.1', ...) 看似一样，但底层协议完全不同：
-
localhost→ Unix socket（Linux/macOS）或命名管道（Windows），对应权限记录是@'localhost' -
127.0.0.1→ 强制走 TCP/IP，对应@'127.0.0.1'
所以如果你只授权了 'app'@'127.0.0.1'，却在 PHP 里写 'localhost'，必然报错。统一策略更安全：开发环境全用 127.0.0.1，避免 socket 差异；生产环境按实际网络拓扑填真实 IP 或域名。
另外，mysqli_connect_error() 必须紧跟连接语句之后打印，不能省。它返回的字符串比错误码更直观，比如 "Access denied for user 'a'@'b'" 直接暴露匹配失败的 host。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
