Go Modules 默认启用，module path需为类URL格式且与import前缀一致；go mod tidy仅保留实际引用的依赖；replace仅当前模块生效，须运行go mod tidy并避免CI中使用本地路径。
Go Modules 是 Go 1.11 引入的官方依赖管理机制，从 Go 1.16 起默认启用——你不需要手动开启 GO111MODULE=on，但必须理解它在什么路径下会自动激活、什么情况下会 fallback 到 GOPATH 模式。
为什么 go mod init 失败或生成了错误的 module path？
根本原因在于当前目录不在 GOPATH/src 下，且未显式指定 module 名称。Go 会尝试从当前路径推导（比如 ~/projects/myapp → 推导为 myapp），但这不是合法的导入路径，会导致后续 go get 或构建失败。
- 务必在项目根目录执行
go mod init example.com/myproject，使用类 URL 的 module path，即使不托管在该域名下——这是 Go 生态约定，影响所有依赖解析和语义化版本识别 - 如果项目已存在
import语句（如import "github.com/user/lib"），module path 应与这些导入前缀一致，否则go build会报cannot find module providing package - 执行后检查生成的
go.mod文件：第一行module example.com/myproject必须准确；若错误写成module myproject，手动修正并运行go mod tidy重载依赖
go mod tidy 为什么删掉我手动 go get 的包？
go mod tidy 只保留当前代码中实际被 import 的包，以及这些包的传递依赖。它不认“下载过”或“本地有”，只认“被引用”。这是设计使然，不是 bug。
- 如果你只是想试用某个包但尚未 import，
go mod tidy会把它从go.mod中移除——正确做法是先写一行import _ "github.com/xxx/yyy"（空导入），再运行go mod tidy，之后再删掉这行 - 若依赖被间接引用（比如通过另一个库引入），但你的代码没直接 import，它仍会被保留在
go.mod中；一旦那个上游库升级并移除了该依赖，go mod tidy下次就会把它删掉 - 慎用
go get -u：它会升级所有依赖到最新版（含 major 版本跃迁），可能破坏兼容性；建议用go get pkg@v1.2.3显式指定版本
如何替换私有仓库或未发布模块（如 fork 后的修复）？
Go Modules 不支持类似 npm 的 resolutions，但提供 replace 指令，它在 go.mod 中生效，且优先级高于远程源。
立即学习“go语言免费学习笔记（深入）”；
- 在
go.mod文件末尾添加：replace github.com/original/lib => ./local-fix
（本地路径）或replace github.com/original/lib => github.com/your-fork/lib v1.2.4-fix
（另一仓库 tag） -
replace只影响当前 module，不会透传给下游；若你发布的库用了replace，下游用户不会继承该替换——这点常被忽略 - 替换后必须运行
go mod tidy，否则go build仍可能拉取原始版本；验证是否生效：查看go.mod中该依赖行是否带// indirect标记，或执行go list -m all | grep original - 生产构建前应删除
replace（尤其指向本地路径的），否则 CI 环境找不到路径会失败
真正容易出问题的不是命令怎么敲，而是 module path 的一致性、replace 的作用域边界、以及 tidy 对“未使用依赖”的零容忍——这些地方一错，编译时不会立刻报错，但会在某次依赖更新后突然失败。
