goroot 和 which go 不一致是因旧 goroot 环境变量覆盖了自动探测路径，需检查并清除 brew/dpkg/系统变量及 shell 配置文件中的 export；go111module=off 会禁用模块功能，应设为 on；缓存和 replace 路径不匹配也会导致依赖异常。
GOROOT 和 which go 不一致就是环境变量在捣鬼
终端里 which go 返回 /usr/local/go/bin/go，但 go env GOROOT 却显示 /home/user/sdk/go —— 这不是安装出错，是旧的 GOROOT= 环境变量还在生效。它会强行覆盖 Go 自己探测到的根路径，导致二进制和标准库“不是一套”。
查来源比删目录更重要：
- macOS：运行
brew list go，确认是否用 Homebrew 装过；如果输出有结果，说明你可能混用了手动解压和 brew 安装 - Ubuntu/Debian：执行
dpkg -l | grep golang，看是否有残留包 - Windows：不只是用户环境变量，得进“系统属性 → 高级 → 环境变量”，在“系统变量”栏里搜
GOROOT，改掉或删掉 - 所有平台：检查
~/.zshrc、~/.bash_profile、/etc/profile里有没有export GOROOT=行，删干净再source对应文件
GO111MODULE=off 会让 go.mod 形同虚设
即使项目里有 go.mod，只要 go env GO111MODULE 是 off，Go 就退化回 GOPATH 模式：不读 replace、忽略 go.sum、go get 行为异常，依赖全乱。
必须强制开启：
- 运行
go env -w GO111MODULE=on（Go 1.16+ 默认开启，但某些旧 shell 初始化脚本会关掉它） - 验证：执行
go env GO111MODULE，输出必须是on - 如果项目在 GOPATH 下且没
go.mod，Go 仍会默认用 GOPATH 模式——别依赖路径判断，只信go env输出
缓存不清理，新装的 Go 也会拉错依赖
rm -rf /usr/local/go 只删了二进制和标准库，$GOPATH/pkg/mod 里的模块缓存、$GOCACHE 里的构建产物全还在。新装的 Go 一跑 go build，就自动读这些旧缓存，轻则版本错乱，重则校验失败、编译出带旧符号的二进制。
清缓存要分层动手：
- 执行
go clean -cache -modcache -i：清构建缓存、模块下载缓存、已安装命令（如go install生成的可执行文件） - 手动删模块缓存：
rm -rf $(go env GOPATH)/pkg/mod，注意这会清空所有已下载依赖，首次go build会慢，但能断绝版本污染 - 检查
go env GOSUMDB，如果之前设成off或私有地址，重装后建议恢复默认：go env -w GOSUMDB=sum.golang.org
replace 生效但没起作用？大概率 import 路径没同步改
写了个 replace github.com/old/pkg => github.com/old/pkg v2.0.0，但代码里还是 import "github.com/old/pkg" —— 这个 replace 根本不会生效。因为 Go 把 v1 和 v2 当作两个不同模块，路径必须匹配。
真正生效的条件：
- 如果目标模块用了语义化版本 v2+，你的
import必须写成github.com/old/pkg/v2，且replace也要对应写github.com/old/pkg/v2 => ... - 用
go list -m all | grep old/pkg看输出里是不是真出现了=>后面是你指定的路径或版本 - CI 构建时若残留本地路径
replace（比如=> ../fix），会直接失败——上线前务必删掉，别靠“注释掉”蒙混
环境变量引发的混乱从来不是孤立问题：它常和缓存、模块路径、MVS 策略咬合在一起。查 go env、清缓存、盯住 go list -m all 的实际输出，比反复重装 Go 更有效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
