Go项目必须用Go Modules，GOPATH和vendor已淘汰；go get是go mod download+tidy的快捷入口，不替代模块机制，需先go mod init；// indirect表示间接依赖，go.sum不可手动编辑，否则构建失败。
Go 项目现在必须用 Go Modules，GOPATH 和 vendor 都已淘汰，不是“可选”，而是“不支持”。
为什么 go get 还能下载包，但不能替代 go mod？
因为 go get 在 Go 1.16+ 默认只修改 go.mod，不再自动写入 GOPATH/src；它本质是 go mod download + go mod tidy 的快捷入口，不是独立的依赖管理机制。
- 直接执行
go get github.com/gin-gonic/gin不会把代码拉到$GOPATH/src，而是下载到全局缓存（$GOCACHE），再记录进go.mod - 如果项目没初始化模块（无
go.mod），go get会报错或静默失败——它不再帮你“创建模块”，必须先go mod init -
go get -u升级依赖时，实际触发的是 MVS（最小版本选择）算法，不是简单取最新 tag，可能降级已有依赖以满足约束
go.mod 文件里 require 行末尾的 // indirect 是什么意思？
表示该依赖不是你代码中直接 import 的，而是某个你显式 require 的包所依赖的间接依赖。
- 例如你
require github.com/sirupsen/logrus v1.9.0，而 logrus 内部用了golang.org/x/sys，后者就会被标记为// indirect - 它不是“多余依赖”，而是构建必需项；删掉会导致
go build失败 - 但若某
// indirect依赖长期未被任何直接依赖引用，go mod tidy会自动移除它
go.sum 文件为什么不能手动编辑？
go.sum 是每个依赖模块的校验和快照，由 Go 工具链自动生成并严格校验，手动改会导致 go build 或 go test 直接失败。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 内容格式为：
路径 版本 h1:xxx（SHA256 哈希）和路径 版本/go.mod h1:xxx（对应 go.mod 文件哈希） - 只要
go.mod变动（如go mod tidy），go.sum就会重算并追加新行，旧行保留用于历史回溯 - 如果遇到校验失败，常见原因是：代理返回了篡改包、本地缓存损坏、或别人提交了没更新
go.sum的go.mod
还在用 GOPATH 或 vendor 目录？那得立刻停用
Go 1.16 起已完全移除对 GOPATH 模式下构建的支持；vendor 目录虽仍被识别，但 go mod vendor 生成的 vendor 不再参与默认构建流程，除非显式启用 GO111MODULE=off（已被弃用）或 -mod=vendor 参数。
-
GO111MODULE=on是当前唯一稳定模式，且从 Go 1.13 起就是默认值，无需设置 - 残留的
vendor/目录会干扰依赖分析，尤其当里面存在过时或冲突版本时，go list -m all输出会异常 - CI/CD 中若看到
go build -mod=vendor，说明项目尚未完成 Modules 迁移，存在隐性构建风险
真正麻烦的不是命令记不住，而是不同 Go 版本对 go.mod 语义的细微调整——比如 Go 1.21 开始要求 go 指令必须 ≥ 当前 Go 版本，否则 go build 报错；这种约束不会在本地开发机上暴露，却会在低版本 CI 环境里突然中断流水线。
