答案是将Navicat连接中的“localhost”改为“127.0.0.1”即可解决，因localhost依赖DNS解析，在Wi-Fi切换或网络异常时易失败，而127.0.0.1直接走IPv4回环、绕过DNS，稳定可靠。
不是wi-fi本身的问题，而是“localhost”解析失败导致的连接中断。
为什么localhost在断网或换Wi-Fi后连不上本地MySQL
Navicat里填localhost时，系统会尝试走IPv6（::1）或IPv4（127.0.0.1）回环地址，但部分系统/网络栈在Wi-Fi切换、DNS服务短暂不可用或IPv6配置异常时，localhost解析会卡住或失败——哪怕数据库服务本身完全正常。这不是Navicat的bug，是操作系统级域名解析行为的副作用。
- 现象：Wi-Fi重连后，Navicat报错
Can't connect to MySQL server on 'localhost'或超时，但mysql -u root -p命令行能连 - 本质：
localhost触发DNS查找，而127.0.0.1直接走TCP/IP栈，绕过DNS - 验证方法：在终端执行
ping localhost，如果卡顿或返回::1而非127.0.0.1，就坐实了这个问题
把localhost换成127.0.0.1就能解决
这是最直接、零成本、100%生效的修复方式。不需要重启服务、改配置、装驱动。
- 在Navicat中右键连接 → “编辑连接” → “常规”选项卡
- 把“主机名或IP地址”从
localhost改为127.0.0.1 - 端口保持默认
3306（除非你改过） - 点“测试连接”，成功后保存
注意：127.0.0.1明确指定IPv4回环，不依赖DNS，也不受网络接口状态影响——断网、切Wi-Fi、禁用以太网，它都稳如磐石。
别碰skip_name_resolve这类MySQL配置
网上有方案建议修改MySQL的my.cnf，加skip_name_resolve=ON来禁用DNS反向解析。这确实能缓解部分远程连接问题，但对本地localhost失效场景无效，反而可能带来副作用：
- 它只影响MySQL服务端对客户端IP的反向解析（比如
SHOW PROCESSLIST里显示主机名），不解决客户端解析localhost失败的问题 - 若你的应用或监控工具依赖主机名识别，开启后可能丢失来源标识
- 需要重启MySQL服务，增加操作风险和停机时间
其他容易被忽略的干扰项
如果改完127.0.0.1还是连不上，说明问题不在DNS解析，得往下查：
- 确认MySQL服务真在运行：
systemctl status mysql（Linux）或服务管理器里看MySQL80状态（Windows） - 检查是否绑定了
127.0.0.1而非0.0.0.0或::1：用netstat -an | grep 3306看监听地址，必须含127.0.0.1:3306 - 防火墙没拦自己：
sudo ufw status（Ubuntu）或Windows Defender防火墙里确认“允许本地程序入站”已开
真正麻烦的从来不是localhost这个词，而是你把它当成一个稳定符号，却忘了它背后是活的DNS和操作系统网络栈。
