确认系统是否有go残留需主动扫描常见路径（如/usr、/opt、~），而非仅依赖which/whereis；发现如/usr/local/go等目录须彻底删除，rpm/yum残留用sudo yum remove -y $(rpm -qa | grep -i golang)清理。
怎么确认系统里有没有残留的 Go 安装
直接执行 which go 和 whereis go 不够，因为旧版本可能没进 PATH，但文件还在磁盘上。更可靠的做法是主动扫描常见路径：
find /usr -name "go" -type d 2>/dev/nullfind /opt -name "go" -type d 2>/dev/null-
find ~/ -name "go" -type d 2>/dev/null（尤其注意家目录下的手动解压）
如果发现任何结果，尤其是 /usr/local/go 或 /opt/go，说明存在手动安装残留，必须删干净再继续。rpm/yum 安装的残留则用 sudo yum remove -y $(rpm -qa | grep -i golang) 清理，但别指望它能删掉所有配置文件。
GOROOT 和 GOPATH 设置到底要不要手动配
Go 1.16 之后，GOPATH 默认为 $HOME/go，且多数命令（如 go install）已支持模块模式，不再强依赖 GOPATH。但如果你用的是老项目或某些工具链（比如旧版 gopls），仍需显式设置。
GOROOT 只有在非标准路径安装时才需要设——比如你把 Go 解压到 /opt/go-1.22.2，那就必须导出 GOROOT=/opt/go-1.22.2；否则留空即可，Go 会自动推导。
真正关键的是 PATH：必须包含 $GOROOT/bin（或安装目录下的 bin），否则 go 命令根本找不到。常见错误是只加了 $GOPATH/bin 却漏了 GOROOT 对应的 bin。
为什么 go version 正常但 go run 报错“cannot find module”
这不是环境变量问题，而是 Go 模块机制触发的路径判断逻辑变了。从 Go 1.11 开始，默认启用模块（module），go run 要求当前目录下有 go.mod 文件，或位于 $GOPATH/src 下（且该路径需匹配 import path）。
解决方法只有两个：
- 在项目根目录运行
go mod init example.com/myapp（随便起个合法模块名），生成go.mod - 或者临时关闭模块模式：
GO111MODULE=off go run main.go（不推荐长期用）
注意：GO111MODULE=on 是默认值，设成 auto 也等价于 on，仅当目录外有 go.mod 时才启用——这个“外”指父目录，不是任意位置。
连接池和 GC 参数这类“全局调优”真能写进环境变量吗
不能。像 SetMaxOpenConns、GOGC、GOMEMLIMIT 这些都不是 shell 环境变量，而是运行时参数或代码中显式调用的配置。误以为设了 export GOGC=50 就生效，结果服务内存飙高才发现没起作用。
正确做法分两类：
-
GOGC、GOMEMLIMIT、GODEBUG这类确实可设为环境变量，但必须在启动 Go 程序前导出，例如：GOGC=200 ./myserver或在 systemd service 文件里写Environment=GOGC=200 -
xorm的SetMaxOpenConns等必须在代码里调用，且要在engine.Open之后、首次使用前完成，晚了就无效
最容易被忽略的是：这些参数之间有隐含依赖。比如只调大 SetMaxOpenConns 却没配 SetConnMaxLifetime，MySQL 空闲超时断连后，Go 连接池不会主动踢掉失效连接，lsof 里就会堆满 CLOSED_WAIT。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
