go modules是go 1.16+强制前提，go111module=on不可关闭，缺失go.mod/go.sum导致构建不可复现；go mod tidy必须执行以校验并补全所有依赖；私有仓库需配goprivate和goproxy=xxx,direct，否则拉取失败。
Go Modules 不是可选插件，而是构建前提
从 Go 1.16 起，GO111MODULE=on 已强制默认，任何试图设为 off 的操作在 Go ≥1.20 中会直接导致 no required module provides package xxx 类错误——不是警告，是构建失败。这意味着：只要用现代 Go（即当前所有稳定版），你就已经在 Modules 里了，逃不掉，也不该逃。
go.mod 文件缺失 = 项目不可复现
没有 go.mod，就没有明确的模块路径、Go 版本声明和 require 列表；没有 go.sum，就无法校验依赖包是否被篡改或替换。常见后果包括：
- 本地能跑，CI 报
import "xxx" not found—— 因为go get在 GOPATH 模式下不会自动发现未声明的间接依赖 - 同事拉代码后
go build失败，只因他机器上缓存了某个依赖的旧版，而你本地恰好用了新版 - 升级一个 minor 版本后 panic，因为没锁版本，
go get拉到了语义不兼容的补丁版（比如v1.12.0→v1.12.1里悄悄改了接口）
go mod tidy 不只是“整理”，而是依赖一致性校验
go mod tidy 并非仅删除未引用的 require 行，它会：
- 扫描全部
.go文件，补全所有实际 import 的依赖（含间接依赖） - 剔除
go.mod中存在但代码里已删掉的require项 - 同步更新
go.sum，确保每个模块哈希值与当前解析结果一致
跳过这步直接提交 go.mod，等于把“半成品依赖图”交给协作方——轻则 go build 报错，重则引入不一致的间接依赖版本。
私有仓库和代理配置稍错一步，整个依赖链就断
国内拉取 golang.org/x/... 或私有 GitLab 仓库时，常见失效点：
-
GOPROXY设成https://proxy.golang.org但没配GOPRIVATE→ 私有模块被代理拒收，报module xxx: reading <code>https://proxy.golang.org/xxx/@v/list: 404 Not Found -
GOPROXY漏掉direct后缀 → 遇到不支持代理的模块（如某些自建 Nexus）时直接卡死，不 fallback - 用
git@地址写require但没配 SSH key 或git config→go mod download提示permission denied (publickey)
这些配置不在 go.mod 里，却决定整个项目能否 go get 成功——它们是环境敏感层，必须文档化、CI 中显式设置，不能靠“我本地能跑”蒙混过关。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
