go clean -cache 有时清不掉问题，因为它只清理 $gocache，而编译还受 cgo_enabled、goos、goarch 等环境变量影响，导致不同构建模式的 .a 文件混存，引发链接失败或符号缺失。
go clean -cache 为什么有时清不掉问题？
直接运行 go clean -cache 看似万能，但实际常失效——它只清 $GOCACHE，而编译行为还受 CGO_ENABLED、GOOS、GOARCH 等环境变量影响。同一缓存目录下混存了不同构建模式的 .a 文件，链接时可能静默失败或符号找不到。
- 改过 Cgo 代码后没清缓存 → 链接阶段报 undefined reference，但错误不明确
-
CGO_ENABLED=0构建过，再切回CGO_ENABLED=1→ 缓存里没对应 cgo 版本的目标文件，build 卡在 linking - Go 1.21+ 切换
GOOS=windows和GOOS=linux→ 缓存不会自动区分，必须手动清 - 缓存路径可通过
go env GOCACHE查看，Linux 默认是$HOME/.cache/go-build
go clean -modcache 清的是什么，什么时候非清不可？
go clean -modcache 删除的是 $GOMODCACHE（通常是 $GOPATH/pkg/mod），里面存着所有模块的 zip 包和解压后的源码。它不校验内容一致性，所以手改过 pkg/mod 里的文件，go build 仍会照用，直到下次 go mod download 覆盖。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 遇到
go mod verify失败但go.sum没报错 → 很可能是本地 zip 损坏，清-modcache后重下 - 从
proxy.golang.org切到私有GOPROXY→ 旧缓存里可能混着同版本不同来源的模块，必须清 - CI 流水线中每次构建前加
go clean -modcache→ 防止跨构建污染，但首次构建会变慢 - 清完后
go mod download会重新拉取全部依赖，耗时取决于网络和模块数量
go clean -i 为什么删不掉已安装的二进制？
go clean -i 只清理「当前目录下 main 包安装生成的二进制」及其关联的 .a 文件，不是全局删除命令。它不扫描 $GOBIN 或 $GOPATH/bin 目录，也不管你之前在哪执行过 go install。
- 你在
~/proj/cmd/myserver执行go install→ 生成$GOBIN/myserver - 然后
cd ~/proj运行go clean -i→ 不生效，因为当前目录没有main包 - 想删干净，得
cd ~/proj/cmd/myserver && go clean -i，或写脚本遍历所有cmd/子目录 - 注意：
go clean -i不影响go build -o xxx生成的临时二进制，只管go install安装的
增量编译到底靠什么，go build -i 还有用吗？
Go 没有真正的增量编译引擎，所谓“增量”其实是靠缓存复用：如果某个包没变，就跳过编译，直接用上次生成的 .a 文件。但这个机制很脆弱，只要依赖链上任一包变了，下游全得重编。
-
go build -i会把编译结果安装到$GOPATH/pkg（或$GOCACHE，Go 1.10+ 默认走后者），下次构建时复用 —— 但它对模块化项目作用有限，尤其当go.mod里用了replace或本地路径时 - 真正提速靠的是
$GOCACHE开启（默认开启），禁用它（GOCACHE=off）会让编译退化成全量重编 - 调试时频繁改
main.go但不动依赖包 → 缓存有效；一旦改了internal/下的工具函数 → 整个依赖树重编 - 大型项目建议用
go build -x观察哪些包被跳过，再结合go list -f '{{.Deps}}' .分析依赖范围
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
