“connection refused”错误90%与Go代码无关，而是运行时环境问题：目标服务未监听指定端口、绑定地址错误（如仅127.0.0.1）、代理/hosts/DNS干扰，或sql.Open未触发实际连接（需db.Ping验证）。
Go程序报“connection refused”不是代码写错了
这个错误90%和go代码本身无关，是运行时环境没准备好。go的net.dial、http.get、sql.open等操作在发起tcp连接时，如果目标地址+端口没有监听服务，操作系统内核会直接返回econnrefused（对应go错误字符串里含connection refused），go只是原样透出——它连重试都不会做，更不会帮你启动mysql或http服务。
先确认目标服务真正在监听指定端口
别急着改Go代码，先验证服务端是否存活且绑对了地址：
- 用
lsof -i :3306（macOS/Linux）或netstat -ano | findstr :3306（Windows）查端口是否被进程占用；没输出=服务根本没起来 - 若看到监听行，检查第二列（Linux/macOS）或“本地地址”列（Windows）：必须包含
0.0.0.0:3306或*:3306，而非仅127.0.0.1:3306——后者只接受本机回环请求，容器或远程调用必拒 - MySQL默认绑定
127.0.0.1，需改配置文件my.cnf中bind-address = 0.0.0.0并重启服务 - Go写的HTTP服务若用
http.ListenAndServe("localhost:8080", nil)，同样只听本地，应改为http.ListenAndServe(":8080", nil)
代理、hosts、DNS三处最容易“无声劫持”连接
Go程序发起连接前，会走系统级网络栈，而代理设置、/etc/hosts或DNS污染可能把你的请求悄悄转向127.0.0.1或一个根本不存在的IP：
- 检查Git或全局代理残留：
git config --get http.proxy，若输出http://127.0.0.1:7890这类内容，Go的http.Client默认会继承系统代理，结果连本地代理端口都失败 - 打开
/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows），搜索github.com、goproxy.cn等域名，临时注释掉所有相关行再试go get -
go env GOPROXY若为https://proxy.golang.org,direct，国内大概率直连失败；执行go env -w GOPROXY=https://goproxy.cn,direct可绕过
Go代码里要主动区分拒绝和超时
很多人把connection refused和timeout混为一谈，但它们的处理逻辑完全不同：前者是服务端明确拒收，重试无意义；后者可能是网络抖动，值得重试。Go里必须用类型断言区分：
if urlErr, ok := err.(*url.Error); ok {
if netErr, ok := urlErr.Err.(net.Error); ok && netErr.Timeout() {
// 是超时，可考虑重试
} else if strings.Contains(urlErr.Err.Error(), "connection refused") {
// 是拒绝，该报错就报错，别盲目重试
}
}
注意：不能只靠strings.Contains(err.Error(), "...")判断，因为错误文本随系统语言变化；但connection refused是POSIX标准错误码对应的固定英文字符串，在所有Go支持平台上都稳定出现，可安全用于关键路径判断。
真正容易被忽略的是：Go的sql.Open不建立物理连接，db.Ping()才触发第一次拨号——所以即使sql.Open成功，db.Ping()报connection refused才是真实问题点。别在Open后就以为万事大吉。
