Go module 是项目级依赖契约，通过 go.mod 文件声明模块名及依赖版本，摆脱 GOPATH 路径限制；go mod init 不自动解析 import 或下载依赖，需 go run/go build 或 go mod tidy 触发；开发时用 replace 临时重定向本地模块；多模块下 go list -m all 仅显示当前目录 go.mod 的依赖；模块名须与实际 import 路径一致。
Go module 是什么？不是“新包管理器”，而是项目级依赖契约
Go module 不是替代 import 的东西，它是一份声明：「这个目录下的所有 Go 代码，属于一个叫 myproject 的逻辑单元，它依赖哪些外部模块、用哪个版本，都以 go.mod 文件为准」。它让 Go 彻底脱离 $GOPATH/src 的路径绑架——项目可以放在 ~/dev/myapp、/tmp/test 甚至 Docker 容器任意路径，只要根目录有 go.mod，Go 就认得这是个独立模块。
为什么 go mod init 后 go run 还报 cannot find package
这是最常踩的坑：go mod init 只生成空的 go.mod，**完全不扫描你的 import 语句，也不下载任何依赖**。你写了 import "github.com/spf13/cobra"，但没运行过拉取动作，Go 就真不知道这玩意儿在哪。
- 正确做法：写完代码后，直接执行
go run main.go或go build—— Go 会自动解析 import、下载对应版本、写入go.mod和go.sum - 更稳妥做法：运行
go mod tidy，它会补全缺失依赖、删掉未引用的依赖，并校验go.sum - 错误做法：只
go mod init就以为万事大吉；或手动编辑go.mod添加require却不触发下载
本地开发时怎么让 A 模块用 B 模块的修改版？别改 import，用 replace
当你在调试 myproject/pkg/auth，同时 myproject/cmd/app 依赖它，你肯定不想先 go install 再 go get——既慢又容易漏推送到远程。Go 不允许你在代码里写 import "./pkg/auth"（相对路径导入非法），但允许你在 go.mod 里声明重定向：
replace myproject/pkg/auth => ./pkg/auth
这样 go build 时就会直接读本地文件，跳过远程下载。注意：replace 是开发期临时手段，CI/CD 发布前应移除，否则别人 clone 你的 repo 就编译不过。
立即学习“go语言免费学习笔记（深入）”；
多个子模块共存时，go list -m all 为啥只显示根模块？
因为 Go 默认只识别当前工作目录下的 go.mod。如果你的项目结构是：
myproject/
├── go.mod # 根模块（可选）
├── service/user/
│ └── go.mod # 独立 module
└── pkg/auth/
└── go.mod # 独立 module那么在 service/user/ 目录下运行 go list -m all 才能看到该模块的完整依赖树；在项目根目录运行，只会看到根 go.mod 声明的内容（如果有的话）。多模块项目没有全局“总依赖图”，每个 go.mod 是自治的——这也是它支持按模块发版、解耦 CI 流水线的基础。
真正容易被忽略的是：模块名（module github.com/you/repo）必须和你未来实际引用它的 import 路径严格一致。比如你设成 module myapp，别人就只能 import "myapp/pkg/util"，而无法通过 GitHub 地址引用——这对开源或跨团队复用是硬伤。起名别图省事，就用仓库地址。
