go mod init仅生成go.mod文件，不下载依赖；依赖仅在首次import后执行go build、go test或go mod tidy时才解析并下载，且必须确保模块路径匹配、网络可达、GOPROXY配置正确。
Go 语言模块依赖在“极客开发版”中并不存在特殊处理机制——它只是普通 Go 环境，所谓“极客开发版”并非 Go 官方术语，也不对应任何特定发行版或定制工具链。所有依赖行为完全由 Go SDK 自身的 go mod 子系统驱动，与你本地安装的 Go 版本（如 go1.21 或 go1.24）严格绑定。
为什么 go mod init 后依赖没自动拉取
执行 go mod init example.com/myapp 只生成 go.mod 文件，不会触碰网络或下载任何依赖。这是设计使然：Go 不会擅自引入外部代码。
- 依赖仅在首次
import并运行go build、go test或显式go get时才解析和下载 - 若项目已有
import "github.com/gorilla/mux"，但go.mod里没这行，go build会报错并提示 “require github.com/gorilla/mux: not found in go.mod” - 此时运行
go mod tidy才会补全依赖并写入go.mod和go.sum
go.sum 校验失败却能编译通过？
默认情况下，Go 仅在校验失败时发出警告（verifying github.com/xxx@v1.2.3: checksum mismatch），但不中断构建——除非你设置了 GOSUMDB=off 或 GOSUMDB=sum.golang.org 且网络异常导致 fallback 失败。
- 真正阻断构建的是
GO111MODULE=on+GOSUMDB=off+go.sum存在但内容被手动篡改 - 国内常见误操作：为绕过代理问题直接删掉
go.sum，结果下次go mod download会重新生成，但历史校验记录丢失 - 安全建议：保留
go.sum，用go mod verify主动检查，而非依赖构建时的被动提示
私有模块拉取总卡在 403 或 unknown revision
根本原因不是 Go 本身限制，而是 GOPROXY 和认证机制未对齐。Go 默认走 https://proxy.golang.org，该代理无法访问私有仓库。
立即学习“go语言免费学习笔记（深入）”；
- 必须关闭代理：设置
GOPROXY=direct，否则即使配置了git config认证，请求也会先被 proxy 拦截 - 确保 Git 能直连私有地址：运行
git ls-remote https://git.example.com/myorg/mymodule.git测试是否返回 ref 列表 - 若用 SSH 地址（如
git@example.com:myorg/mymodule.git），需确认~/.ssh/config中 Host 别名已正确映射，且ssh -T git@example.com可通 -
go get时显式指定版本（如go get git.example.com/myorg/mymodule@v0.3.1）比不带版本更稳定，避免 Go 去查 latest tag
最容易被忽略的一点：Go Modules 的版本解析完全基于 Git tag（v1.2.3 格式），不是分支名、不是 commit hash（除非显式指定）。哪怕你在 go.mod 里写了 require my.private/repo v1.2.3，如果远端仓库根本没有打这个 tag，go mod tidy 就会静默失败或 fallback 到 pseudo-version（形如 v0.0.0-20240520123456-abcdef123456），而这种版本无法被其他项目可靠复现。
