go list -m -f '{{.Dir}}' module@version 返回真实路径即表示已下载，否则未下载或版本不存在；go mod download 仅拉取不校验，完整性由 go mod verify 保障。
怎么确认本地是否已下载某个模块版本
直接查 $GOPATH/pkg/mod 目录最可靠。Go 不会在构建时重复下载已缓存的模块，但不会主动告诉你“这个版本已存在”。
运行：go list -m -f '{{.Dir}}' github.com/gin-gonic/gin@v1.9.1
如果返回一个真实路径（如 /home/user/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1），说明该版本已下载；若报错 no matching versions 或路径为空，则未下载或版本不存在。
注意：go mod download 不会验证已下载模块的完整性，只负责拉取；真正校验靠 go mod verify。
多个子项目间如何统一依赖版本号
关键不是“同步下载”，而是“同步声明”——所有子模块的 go.mod 必须对同一依赖使用相同版本号，否则 go build 时可能因版本冲突失败。
常见错误现象：A 模块 require example.com/lib v0.3.0，B 模块 require example.com/lib v0.2.5，即使两者都已下载，主模块整合时仍可能触发版本仲裁失败。
实操建议：
• 在根目录（或主模块）执行 go mod edit -require=example.com/lib@v0.3.0 统一写入
• 然后在每个子模块目录下运行 go mod tidy，它会自动对齐间接依赖并清理冗余项
• 若子模块有独立 go.mod 且不共享主模块的依赖树，需手动检查并统一 require 行
• 避免混用 @latest 和具体版本号，否则 go list -m all 输出会显示不同伪版本，难以比对
为什么 go mod download 不能保证多项目版本一致
go mod download 只按当前目录下的 go.mod 下载依赖，它不关心其他目录的 go.mod 内容，也不会跨项目去“对齐”版本。
典型陷阱：
• 你在 service/ 下运行了 go mod download，它下载了 shared@v0.4.0
• 但在 cli/ 下的 go.mod 里写的是 shared@v0.3.2，你没运行过 go mod download，结果 CI 构建时才发现缺失
• 更隐蔽的是：两个模块都用了 replace example.com/shared => ../shared，但本地 ../shared 的 commit 不同，go mod download 完全不感知这种差异
所以真正起作用的是 go.sum 哈希值 + go.mod 版本声明，不是下载动作本身。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
CI 中如何自动化检测多项目依赖一致性
把校验逻辑放进 CI 脚本，比人工核对更可靠。
推荐步骤：
• 对每个子模块目录，运行 go list -m -f '{{.Path}} {{.Version}}' all | sort > deps-$(basename $PWD).txt
• 合并所有 deps-*.txt，用 sort | uniq -c | grep -v '^\s*1 ' 找出不一致的模块路径与版本组合
• 加上 go mod verify 确保每个模块的 go.sum 未被篡改
• 如果使用 go.work，必须在工作区根目录运行 go work sync，否则各子模块的 go.mod 可能脱离工作区约束
容易被忽略的一点：go list -m all 默认只输出直接+间接依赖，但若某子模块用了 replace 指向本地路径，它不会出现在列表中——得额外检查 go mod graph 或解析 go.mod 文件本身。
立即学习“go语言免费学习笔记（深入）”；
