go mod init 的模块路径必须与代码实际存放位置匹配，否则会导致 import 找不到包；推荐在项目根目录不带参数执行以自动推断，或手动指定合理路径并保持所有 import 一致；初始化后须立即运行 go mod tidy 才完成依赖解析与校验。
go mod init 不是“随便选个模块名就能跑”，它直接决定后续 go get、go build 和依赖解析行为，错误命名会导致本地开发失败、CI 构建报错、甚至无法发布到私有代理。
go mod init 后模块路径必须与代码实际存放位置匹配
模块路径（如 github.com/yourname/project）不是随意起的别名，而是 Go 工具链查找 go.mod 和解析 import 语句的依据。如果项目放在 /home/user/myapp，却执行 go mod init example.com/foo，那么所有 import "example.com/foo/..." 都会找不到本地包——除非你真把代码放到了对应域名路径下。
- 推荐做法：在项目根目录下执行
go mod init时不带参数，Go 会尝试从当前路径推断（比如路径含github.com/xxx/yyy就自动用它） - 若路径不规范（如
~/dev/myproj），就手动指定一个合理路径，例如go mod init myproj，并确保所有import都以myproj开头 - 一旦
go.mod生成，就不要轻易改module行——改了就得同步更新所有import，且已有二进制可能因 import path 变更而无法加载
go mod init 后立即运行 go mod tidy 才算真正初始化完成
只执行 go mod init 只是创建空的 go.mod 文件，不记录任何依赖，也不校验现有代码里的 import 是否合法。真正让模块“活起来”的是 go mod tidy：它会扫描全部 .go 文件，补全缺失的依赖、删除未使用的模块，并写入 go.sum 校验和。
- 常见错误：写完
main.go就直接go run .，结果报cannot find module for path xxx—— 因为没运行tidy，导入的第三方包还没被声明 - 执行
go mod tidy前，确保GO111MODULE=on（1.16+ 默认开启，但某些旧环境或 shell 配置可能关着） - 如果项目含子模块（如
cmd/、internal/），tidy会一并处理，无需额外命令
go mod init 时指定版本控制远程地址会影响 proxy 行为
模块路径里带域名（如 github.com/you/repo）会让 Go 工具链默认走 GOPROXY（如 https://proxy.golang.org）拉取依赖；而纯本地名（如 mytool）则完全绕过代理，只查本地 $GOPATH/pkg/mod 和直接 git clone —— 这在离线环境有用，但在 CI 或团队协作中容易导致依赖不一致。
立即学习“go语言免费学习笔记（深入）”；
- 私有仓库要能被正确识别，需满足两个条件：模块路径匹配 Git URL（如
git@gitlab.example.com/group/proj对应gitlab.example.com/group/proj），且配置了git config或GOPRIVATE -
GOINSECURE只对 HTTP 协议仓库生效，对 HTTPS 私仓无效；真正要用私仓，优先设GOPRIVATE=gitlab.example.com/* - 别用
go mod init生成类似file:///path/to/local这种路径——Go 不支持文件协议作为模块路径
go mod init example.com/myserver go mod tidy go run main.go
模块路径一旦写进 go.mod，就成为整个项目的 import 根基。改它不像改变量名那么简单，牵一发而动全身——尤其当项目已提交、有外部引用、或上了制品库时，重命名成本远超预期。
