模块缓存默认开启，自动存储解压校验后的模块副本于GOMODCACHE（默认$GOPATH/pkg/mod），go build等命令自动复用；需避免CI中误清缓存或错误配置路径。
模块缓存默认开启，无需手动启用
Go 1.11 引入模块（go mod）后，模块下载与构建的中间产物就自动缓存在本地。只要 GOPATH 和 GOMODCACHE 环境变量未被显式禁用或重定向，go build、go test 等命令都会复用已缓存的模块源码和编译结果。你不需要写任何配置，也不需要调用额外函数——缓存行为由 cmd/go 内置逻辑控制。
常见误解是以为要“开启缓存”，其实更该关注的是“别意外清空它”。比如在 CI 中反复执行 go clean -modcache，或误将 GOMODCACHE 指向一个临时目录，都会让缓存失效。
查看和清理缓存路径：用 go env GOMODCACHE 定位
GOMODCACHE 是模块解压后的只读副本存放位置，默认在 $GOPATH/pkg/mod 下。它不是源码仓库镜像，而是经过校验、解压、重命名（含校验和后缀）后的稳定快照。
- 运行
go env GOMODCACHE查看当前路径 - 缓存中每个模块形如
github.com/sirupsen/logrus@v1.9.3→ 实际目录名是github.com/sirupsen/logrus@v1.9.3+incompatible或带完整校验和（如v1.9.3-0.20230516142758-4a9e2381ee3d） - 手动清理某模块？直接删对应子目录即可；清空全部？用
go clean -modcache（注意：这会强制下次构建重新下载并解压所有依赖） - CI 场景建议保留缓存目录（如 GitHub Actions 的
actions/cache缓存$GOPATH/pkg/mod），避免重复拉取
缓存不加速 go list -m all 或 go mod graph
这些命令主要解析 go.mod 文件和模块元数据，不涉及源码编译或包加载，因此几乎不读取 GOMODCACHE 中的解压内容。它们的耗时取决于模块树深度、网络解析速度（如查询 proxy.golang.org）以及本地 go.sum 校验完整性。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
如果你发现 go list -m all 变慢，优先检查：
- 是否启用了私有模块代理但配置了错误的
GOINSECURE，导致部分请求 fallback 到慢速 direct 模式 -
go.mod中是否存在大量未收敛的replace或exclude，迫使 go 工具链反复重算版本 - 是否在非 module-aware 模式下运行（即当前目录无
go.mod或GO111MODULE=off），此时命令行为完全不同
交叉编译时缓存仍生效，但 build cache 是另一回事
模块缓存（GOMODCACHE）和构建缓存（$GOCACHE，默认 $HOME/Library/Caches/go-build 或 $XDG_CACHE_HOME/go-build）是两个独立机制：
-
GOMODCACHE存源码，供go list、go build加载包用 -
$GOCACHE存编译后的对象文件（.a）、汇编结果、测试结果等，影响go build -o和go test速度 - 交叉编译（如
GOOS=linux GOARCH=arm64 go build）会生成不同目标的对象文件，但模块源码仍复用同一份GOMODCACHE，不重复下载 - 若想彻底提速 CI 构建，应同时缓存
$GOCACHE和$GOPATH/pkg/mod，二者缺一不可
容易被忽略的一点：go run main.go 在首次执行时会触发模块下载、编译、链接全流程，后续相同命令若没改代码，$GOCACHE 能跳过编译，但 GOMODCACHE 始终只是“被读取”的角色——它本身不参与编译加速，只是保证“有得读”。
