MySQL 间歇性 1045：不是密码玄学，localhost 走了另一条路
我平时很少写踩坑手记，但这次遇到的问题实在太典型了：我的用户名密码一直都是 root/root，可 MySQL 连接有时候能成功，有时候直接报 1045 错误。如果我只盯着「密码是不是被改了」「是不是权限丢了」这些方向排查，只会在原地打转，根本找不到问题根源。
一、我遇到的真实现象
在我的项目里，PDO 连接和数据库客户端都会偶发报错，本质就是 MySQL 直接拒绝了我的认证。我在同一台电脑上用官方客户端测试，得到了非常清晰的结果：
主机填写
127.0.0.1：连接稳定成功，一次都没失败过。主机填写
localhost或::1：稳定触发 1045 错误。
这个现象让我立刻意识到：问题绝对不是密码随机失效，而是我连接到的根本不是同一个 MySQL 服务端，或者 localhost 解析走了完全不同的通道。
二、我发现的第一层真相：bind_address 只绑定了 IPv4
我先在能正常连接的 IPv4 环境下执行了两条命令：
SHOW VARIABLES LIKE 'bind_address'; SHOW VARIABLES LIKE 'port';
查询结果显示 bind_address = 127.0.0.1，我一下就明白了：我的 Mysqld 只在本机 IPv4 回环地址上监听 TCP 连接，完全没有在 IPv6 的 [::1] 上提供服务。
三、我理清的第二层真相：localhost 优先解析成 IPv6
我查了一下，在 Windows 以及很多现代开发环境中，解析 localhost 时，系统会优先返回 IPv6 地址 ::1。我的应用没有强制使用 IPv4，所以客户端会自动尝试连接 [::1]:3306。
这时候就会出现两种我遇到的情况：
3306 端口上根本不是我用的这个 Mysqld：我电脑上有其他进程监听了
[::1]:3306，可能是 IDE、端口转发工具或者其他中间件，我相当于连错了 MySQL 实例。就算协议能对上，
root@'localhost'的权限匹配规则，和 IPv4 + 127.0.0.1 的连接路径完全不一样，自然会登录失败。
我用 netstat 查看 3306 端口后发现：IPv4 和 IPv6 的监听 PID 完全不同，这就是我连错服务的铁证。
四、我为什么会觉得是「间歇性」故障？
排查到这里我也想通了：我电脑上不同程序、框架、配置文件的数据库地址写法不一致，有的写死了 127.0.0.1，有的用了默认的 localhost；再加上连接池、配置热更新，我看到的效果就是「同样的密码有时候能登录，有时候不行」。
其实根本不是玄学，核心原因就是我的数据库连接链路不统一。
127.0.0.1:3306，但 localhost/::1 把我的连接流量引到了另一条完全不同的线路上，所以才出现「同样密码两条命」的情况。五、我自己的处理方案（按优先级排序）
我把所有项目、工具的数据库地址统一改成
127.0.0.1，不再混用 localhost。这是改动最小、最快解决问题的方法。我排查了
[::1]:3306端口占用：用netstat -ano找到 PID，再用tasklist定位进程，关掉了占用端口的工具转发。如果我以后想长期用 localhost 连接，我会修改 Mysqld 的 bind_address 配置，让它同时监听 IPv4/IPv6，再重启服务，从根本上解决问题。
六、我自用的自检命令（可以直接复制）
netstat -ano | findstr ":3306" tasklist /FI "PID eq <上一步输出的 PID>" REM 我用来二分验证的命令 mysql -h 127.0.0.1 -P 3306 -u root -p -e "SELECT 1" mysql -h localhost -P 3306 -u root -p -e "SELECT 1"
七、我整理的问题对照表
| 我看到的表象 | 我找到的真实原因 |
|---|---|
bind_address 为 127.0.0.1 | MySQL 仅监听 IPv4，和 ::1 是两条独立线路。 |
127.0.0.1 正常、localhost 报错 | localhost 被解析成 IPv6，连接到了错误的端口/进程。 |
| 间歇性 1045 错误 | 配置混用 localhost/127.0.0.1，或者 IPv6 端口被占用。 |
我把这次踩坑经历写出来，就是想帮大家和我一样跳出「密码错误」的固定思维，把排查方向拉回到TCP/IP 监听地址、本机端口占用上，这才是解决这类 1045 问题最高效的路径。
