答案是将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、禁用以太网，它都稳如磐石。

navicatmysql

Navicat For MySQL

下载

别碰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和操作系统网络栈。