Go Modules 是当前唯一推荐的依赖管理方式，自 Go 1.11 引入、1.16 起默认启用，vendor 和 GOPATH 模式已退出主流；必须显式 go mod init 初始化，正确设置模块路径，区分 go get 与 go mod tidy 职责，严格提交 go.mod 与 go.sum，并注意 indirect 依赖版本冲突风险。
Go Modules 是当前唯一推荐的依赖管理方式
Go 1.11 引入 go mod，1.16 起默认启用，vendor 目录和 GOPATH 模式已彻底退出主流。如果你还在用 dep 或手动维护 vendor，现在迁移是刚性需求——不仅因为工具链不再支持，更因为模块校验（go.sum）和语义化版本解析（go.mod 中的 v1.2.3）只在 Modules 下可靠生效。
初始化项目时必须显式执行 go mod init
不要依赖 IDE 自动创建或跳过这步。即使项目暂无外部依赖，go mod init example.com/myapp 也会生成最小可用的 go.mod，否则后续 go get 可能误将本地路径当模块路径，导致 replace 失效或版本解析混乱。
-
go mod init的参数应为模块路径（如公司域名+项目名），不是任意字符串，它会影响其他项目 import 该模块时的路径一致性 - 若项目已有
import语句指向旧GOPATH路径，需先统一改为新模块路径，再运行go mod tidy - 执行后立即检查生成的
go.mod：第一行module声明、第二行go版本号（建议与go version输出一致）
go get 和 go mod tidy 的分工必须分清
go get 是「主动引入」操作，会修改 go.mod 并下载指定版本；go mod tidy 是「被动清理」操作，只保留当前代码实际 import 的依赖，删掉未使用的、补上缺失的。混用会导致版本漂移或遗漏。
- 添加新依赖：用
go get github.com/sirupsen/logrus@v1.9.3（带版本号更可控），避免go get github.com/sirupsen/logrus默认拉 latest 导致不可控升级 - 删除依赖：删掉所有
import后，必须运行go mod tidy，否则go.mod里残留的 require 项仍会被构建系统读取 - 升级全部依赖：不推荐直接
go get -u，应逐个指定版本或使用go list -u -m all查看可升级项后再手动更新
go.sum 文件不能手动编辑，但需纳入 Git 提交
go.sum 记录每个依赖模块的校验和，是防篡改的关键凭证。CI/CD 流程中若缺失该文件，go build 会失败（除非加 -mod=mod 参数绕过，但不安全）。
JTBC CMS(5.0) 是一款基于PHP和MySQL的内容管理系统原生全栈开发框架，开源协议为AGPLv3，没有任何附加条款。系统可以通过命令行一键安装，源码方面不基于任何第三方框架，不使用任何脚手架，仅依赖一些常见的第三方类库如图表组件等，您只需要了解最基本的前端知识就能很敏捷的进行二次开发，同时我们对于常见的前端功能做了Web Component方式的封装，即便是您仅了解HTML/CSS也
立即学习“go语言免费学习笔记（深入）”；
- 每次
go mod download或go build都可能更新go.sum，尤其首次拉取新依赖或依赖子模块变更时 - 如果 CI 报错
checksum mismatch，大概率是某依赖的 tag 被强制覆盖（如作者重推 v1.0.0），此时应联系上游或临时用replace指向 commit hash - 团队协作中，有人删了
go.sum再go mod tidy会生成全新校验和，导致其他人go build失败——务必把它和go.mod一起提交
真正容易被忽略的是间接依赖（indirect）的版本锁定：当你依赖 A，而 A 依赖 B v1.1.0，但你的代码也直接 import 了 B，此时 go.mod 中 B 的版本由你显式声明决定，而非 A 的要求。这种隐式冲突不会报错，却可能导致运行时行为不一致。
