go mod init 必须在项目根目录执行，因为会基于当前路径推导模块路径，否则 go.mod 中的模块名与实际 import 路径不一致，导致构建时出现 cannot find module providing package 错误。
go mod init 为什么必须在项目根目录执行
因为 go mod init 会基于当前路径推导模块路径（module path），如果不在目标项目根目录，生成的 go.mod 文件里写的模块名很可能和实际导入路径不一致，后续 go build 或 go run 时会报 cannot find module providing package 错误。
常见误操作：在父级目录或子目录里执行，比如项目结构是 ~/myproj/cmd/app/main.go，却在 ~/myproj/ 下运行 go mod init，结果模块名变成 myproj，但代码里 import 的却是 myproj/cmd/app —— Go 工具链无法匹配。
- 正确做法：cd 进入包含 main 包或首个 Go 文件的最外层目录（通常是
main.go所在目录）再执行 - 模块路径建议与代码托管地址一致，例如 GitHub 仓库
github.com/user/repo，就用go mod init github.com/user/repo - 如果只是本地开发暂无远程地址，可用占位符如
example.com/myapp，后续迁移时只需改go.mod第一行，不需改 import 语句
go mod init 后 go.mod 文件没生成或内容为空
这通常是因为当前目录下没有 .go 文件，或者所有 Go 文件都属于 package main 但没被识别为“可构建入口”。Go 1.16+ 要求至少有一个非测试的 .go 文件存在，且不能全是 package main 而无其他依赖引用（极简情况可能触发惰性初始化）。
- 检查是否漏掉了
.go文件：运行ls *.go确认存在 - 若只有
main.go，尝试加一句import _ "fmt"（哪怕不用），让 Go 感知到潜在依赖 - 手动指定模块路径可绕过自动推导：例如
go mod init myapp，即使没 .go 文件也会生成基础go.mod - 注意：空
go.mod不会报错，但后续go build会失败，务必验证文件内容是否含module和go行
go mod init 之后依赖没自动下载怎么办
go mod init 只初始化模块元信息，不拉取任何依赖。依赖是在首次执行 go build、go run 或显式调用 go mod tidy 时才解析并下载的。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go build后仍提示no required module provides package，说明代码里 import 的路径未被模块声明覆盖，检查 import 路径是否拼写错误或对应包确实不存在 - 想一次性拉取所有依赖并清理未使用项：执行
go mod tidy（它会读go.mod+ 扫描源码 + 补全 require + 删除未用项） - 如果项目用了 replace 或 exclude，
go mod tidy会尊重这些配置，但不会自动添加 —— 替换路径需手动写进go.mod - 国内用户常因 GOPROXY 默认值导致超时，可临时设置：
go env -w GOPROXY=https://goproxy.cn,direct
go mod init 初始化后如何验证是否生效
最直接的方式是看 go list -m 输出和 go build 是否成功，而不是只盯着 go.mod 文件是否存在。
- 运行
go list -m应输出模块路径，如github.com/user/repo；若输出command-line-arguments，说明当前不在模块内或go.mod未被识别 - 执行
go build -o ./bin/app .，成功生成二进制即模块系统已接管依赖解析 - 检查
go.mod中的go版本号是否符合预期（如go 1.21），它会影响泛型、切片操作等语法支持范围 - 注意
go.sum文件可能延迟生成 —— 它只在首次下载依赖后出现，不是go mod init的职责
模块路径一旦写入 go.mod，后续所有 import 都要严格匹配这个前缀；改路径不是改一个文件的事，得同步调整所有 import 语句和 CI/CD 中的构建上下文。这点容易被低估。
