GOROOT是Go安装根目录，存放编译器、标准库等核心文件；GOPATH在模块模式下仅用于go install的二进制输出路径（$GOPATH/bin），不再管理源码和依赖。
go env 里 GOROOT 和 GOPATH 的实际作用是什么
GOROOT 是 Go 安装路径，指向 go 二进制和标准库所在位置；GOPATH 在模块模式下已退居二线，仅用于存放 go install 生成的可执行文件（即 $GOPATH/bin），不再是源码根目录。
常见错误现象：运行 go run main.go 成功，但 go install . 后命令在终端中找不到——大概率是 $GOPATH/bin 没加进 PATH，或 go env GOPATH 输出路径与 PATH 中配置不一致。
- macOS/Linux：确认
export PATH=$PATH:$GOPATH/bin已写入~/.zshrc或~/.bash_profile，且执行过source ~/.zshrc - Windows：检查系统环境变量中
%GOPATH%\bin是否在PATH里，且%GOPATH%值与go env GOPATH输出一致 - 新版 Go（≥1.16）默认启用模块模式，
GO111MODULE=on不再需要手动设置；若误设为off，会导致go mod init失效、依赖拉取失败
go build -ldflags="-s -w" 这类宏编译参数的真实效果
-s 去掉符号表，-w 去掉 DWARF 调试信息，两者合用可让二进制体积减少 30%–50%，但会丧失堆栈追踪精度和 pprof 分析能力。
使用场景：生产环境发布、CI/CD 构建轻量镜像；调试阶段禁用，否则 panic 日志只显示地址而非函数名行号。
立即学习“go语言免费学习笔记（深入）”；
-
go build -ldflags="-s -w"：适合交付给客户的最终二进制，无调试需求 -
go build -ldflags="-X main.version=1.2.3"：注入版本号到变量main.version，需确保该变量声明为var version string -
go build -buildmode=c-shared：生成 C 兼容的动态库（.so/.dll），此时-ldflags大部分无效，需额外链接 C 运行时
国内环境下 GOPROXY 和 GOSUMDB 必须配对调整
只配 GOPROXY 不调 GOSUMDB，拉包时仍会卡在 checksum 校验环节；典型错误是 verifying github.com/sirupsen/logrus@v1.9.0: checksum mismatch。
七牛云代理 https://goproxy.cn 对应的校验服务是 sum.golang.org，但国内直连不稳定，必须显式降级：
- 推荐组合：
go env -w GOPROXY=https://goproxy.cn,direct+go env -w GOSUMDB=off（完全关闭校验，适合内网或可信私有模块） - 折中方案：
go env -w GOSUMDB=sum.golang.google.cn（官方中国镜像，比sum.golang.org可靠） - 私有模块场景：用
go env -w GOPRIVATE=git.example.com/internal排除代理和校验，避免泄露内部地址
go mod tidy 为什么有时不生效或反复增删依赖
根本原因不是命令问题，而是 go.mod 文件里 require 条目和实际代码 import 路径不匹配，或存在未清理的 _test.go 文件引用了已移除的包。
容易被忽略的点：IDE（如 VS Code）可能缓存旧 import 行，保存后没触发 go mod tidy 自动执行；手动运行时又因当前目录不在 module 根而失败。
- 先确认在项目根目录（含
go.mod的目录）执行go mod tidy - 检查是否有
import _ "xxx"形式隐式引用（比如驱动注册），这类 import 不会被静态分析识别，但影响依赖图 - 运行
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./...查看真实依赖树，比go mod graph更准
GOPROXY=direct 时 go build 会尝试直连 proxy.golang.org，而该域名在国内 DNS 解析常超时——这和 -ldflags 无关，但会导致构建卡住，让人误以为是编译参数问题。 
