go mod init 只创建go.mod 文件，声明模块路径并设为根目录，不生成 go.sum 或目录结构；重复执行不覆盖，除非加 -force。
go mod init 会创建什么文件
go mod init 命令只生成一个 go.mod 文件，不创建 go.sum，也不初始化任何目录结构或样板代码。它只是声明当前目录为模块根目录，并记录模块路径（module path）。
常见错误是以为运行后就能直接 go run 或自动下载依赖——其实不会。模块初始化后，首次 go build 或 go run 才会触发依赖解析，并生成 go.sum。
- 模块路径一般用域名（如
github.com/yourname/project），但本地开发可临时用任意合法路径（如myapp），只要不和已发布模块冲突 - 如果当前目录在
$GOPATH/src下且路径匹配某个已知 import 路径，go mod init可能自动推断 module path；否则必须显式指定，否则报错go: cannot determine module path - 重复执行
go mod init不会覆盖已有go.mod，除非加-force参数（极少需要）
为什么 go.mod 里 module 名和 import 路径要一致
Go 工具链靠 go.mod 中的 module 声明来解析所有 import 语句。如果写成 module myproj，但代码里写 import "github.com/you/repo"，go build 会报错：import "github.com/you/repo" is a program, not an importable package 或更隐蔽的 no required module provides package。
本质是 Go 没有“项目名”概念，只有“模块路径”——它既是模块唯一标识，也是所有内部 import 的基准前缀。
- 发布到 GitHub 后，其他人
go get github.com/you/repo，实际拉取的就是你go.mod里声明的module github.com/you/repo - 本地调试时若用假路径（如
module local/test），则所有import也必须以local/test/xxx开头，否则无法解析 - 重命名模块？改
go.mod第一行 + 全局替换所有import路径，缺一不可
go mod tidy 和 go get 的行为差异
go mod tidy 是“清理+补全”：删掉 go.mod 中未被任何 .go 文件引用的依赖，同时添加当前代码实际 import 但缺失的模块。它不关心命令行参数，只看源码。
go get 是“主动引入”：下载指定包（及它的依赖），并更新 go.mod。加 @version 还能精确控制版本（如 go get golang.org/x/net@v0.25.0）。
- 仅想升级某个依赖？用
go get example.com/pkg@latest，别用tidy—— 它不会主动升版，只会按需拉取 - 误加了依赖又删了 import？立刻
go mod tidy，否则go.mod里还留着残留项 -
go get -u已废弃（Go 1.16+），它曾尝试升级间接依赖，现在统一由go get pkg@version显式控制
GO111MODULE=on 是默认值，但某些场景仍需手动设
Go 1.16+ 默认开启模块模式（GO111MODULE=on），但有两个典型例外：
- 当前目录不在模块根下，且路径位于
$GOPATH/src内（比如$GOPATH/src/github.com/xxx/yyy），此时 Go 仍可能 fallback 到 GOPATH mode，导致go mod init失败或依赖不生效 - CI 环境中某些旧脚本或容器镜像可能显式设了
GO111MODULE=auto或off，结果go build报cannot find module providing package
最稳做法是在项目根目录执行：
export GO111MODULE=on go mod init example.com/myapp
或者直接在命令前加环境变量（尤其 CI）：
GO111MODULE=on go mod init example.com/myapp
模块路径一旦写进 go.mod，后续几乎所有 Go 命令都自动走模块模式，但初始化那一刻的环境变量决定能否成功落地。
