go mod 用于解决依赖冲突和构建失败，只要存在 go.mod 文件即启用；报错“no required module provides package”通常因未执行 go mod init 但上级目录有 go.mod 导致自动进入 module 模式。
go mod 不是用来“学”的，是拿来解决依赖冲突和构建失败的——只要 go.mod 文件存在，你就已经在用它了。
为什么 go build 突然报 no required module provides package
这是最典型的 go mod 启用后反直觉的报错：项目没加 go mod init，但当前目录或父目录有 go.mod，导致 Go 自动进入 module 模式，却找不到对应模块定义。
- 检查当前路径下是否存在
go.mod（包括上级目录，Go 会向上查找） - 如果只是临时测试，加
-mod=mod或-mod=readonly强制跳过 module 校验（不推荐长期用） - 正式项目务必在根目录执行
go mod init example.com/myapp，模块名不一定要可访问，但要唯一、有意义 - 别用本地路径（如
./mylib）当模块名，Go 会把它当相对导入，后续go get会失效
go get 加不加 -u、-m 到底影响什么
go get 在 module 模式下本质是“更新依赖声明 + 下载代码”，不是单纯安装工具。
- 不加任何 flag：
go get github.com/sirupsen/logrus→ 只升级该包到最新 tagged 版本，并写入go.mod - 加
-u：go get -u github.com/sirupsen/logrus→ 升级该包及其所有直接依赖（递归到顶层） - 加
-m：go get -m github.com/sirupsen/logrus→ 只修改go.mod，不下载源码（适合手动编辑后同步） - 想锁死版本？直接改
go.mod里的github.com/sirupsen/logrus v1.9.3，再运行go mod tidy
CI/CD 里 go mod download 和 go mod verify 必须跑吗
必须。module 模式下 go build 默认不校验 checksum，靠 go.sum 记录哈希值，但不会自动比对。
-
go mod download预先把所有依赖拉到本地缓存（$GOPATH/pkg/mod），避免构建时网络失败 -
go mod verify检查已下载模块是否与go.sum一致，防篡改；CI 中建议加上，失败即中断 - 别信
GO111MODULE=off能绕过问题——它会让 Go 回退到 GOPATH 模式，但很多新库已不支持 GOPATH 构建 - 私有模块？确保
GOPROXY配置正确（比如https://proxy.golang.org,direct），并用git config或~/.netrc处理私有仓库认证
最容易被忽略的是 go.sum 文件本身：它不是“锁文件”，而是每个依赖版本的哈希快照；删掉它再 go mod tidy，会重新生成，但可能引入不同 commit —— 尤其当上游删了 tag 时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
