go mod init 报“cannot find module root”是因为当前目录不在 gopath/src 下且无上层 go.mod，需cd至项目根目录再执行；模块名决定import路径，必须全局一致且符合规范。
go mod init 为什么总报错“cannot find module root”
执行 go mod init 时提示这个错误，不是因为你没写对命令，而是当前目录不在 GOPATH/src 下、且 Go 找不到上层 go.mod 文件——它需要一个明确的模块根路径。Go 不会自动向上遍历到有 go.mod 的父目录，除非你显式指定模块名或切换到正确位置。
- 最常见场景：你在项目子目录（比如
cmd/myapp）直接运行go mod init，但模块应该以项目根为准 - 正确做法是 cd 到项目最外层目录（即将来放
main.go或go.mod的地方），再运行go mod init example.com/myproject - 如果不想手动输域名，用
go mod init（不带参数）也行，Go 会尝试从当前目录名推导模块路径，但可能推成myproject这种本地名，后续 import 时容易冲突 - 模块名一旦写进
go.mod，所有内部import都得匹配它；改名必须同步改所有 import 路径，否则编译失败
模块名该写 github.com/user/repo 还是随便起个名字
模块名不是“项目名”，而是 Go 包导入路径的根。它直接影响别人怎么 import 你的代码，也影响 Go 工具链解析依赖的方式。
- 如果你的代码会公开、被他人引用（比如开源库），必须用真实可解析的域名路径，例如
github.com/user/mylib；否则别人go get时会失败 - 如果是纯内部项目、不发布，可以用假域名如
internal/myapp，但要注意：CI/CD 或多仓库协作时，这种名字无法被 Go proxy 缓存，也不支持语义化版本 - 模块名里不能含大写字母或下划线（Go 规范限制），
MyApp或my_app都非法 - 如果模块名和实际 Git 地址不一致（比如模块名写成
example.com/foo，但代码托管在github.com/bar/foo），go get可能拉错源，或触发重定向警告
go mod init 后 go build 报 “imported and not used” 或找不到包
这不是 go mod init 没生效，而是模块初始化后，Go 开始严格校验 import 路径是否匹配模块名。很多老项目从 GOPATH 切过来，import 路径还是 myproject/handler 这种相对写法，现在必须改成 example.com/myproject/handler。
- 检查所有
import语句：开头必须和go.mod第一行的模块名完全一致（包括大小写） -
go list -m all可确认当前模块是否被识别；如果输出为空或报错，说明go.mod不在有效根目录 - 编辑器（如 VS Code + gopls）可能缓存旧的 import 补全路径，重启 workspace 或删掉
~/.cache/go-build有时能解决误报 - 别在
go.mod同级目录外执行go build，Go 会按当前工作目录找模块，而不是按go.mod位置
要不要在 go mod init 时加 -modfile 或 -compat 参数
日常初始化几乎不需要。这两个参数是给特殊迁移场景准备的：-modfile 用于生成非默认名的 mod 文件（比如临时测试），-compat 强制指定 Go 版本兼容性（如 v1.16），但 Go 1.17+ 默认已启用 module 模式，且兼容性由 go 指令行版本决定，不是靠这里控制。
立即学习“go语言免费学习笔记（深入）”；
- 普通项目直接
go mod init example.com/name就够了，别加多余参数 -
-modfile容易导致后续go get仍写入默认go.mod，造成双文件混乱 -
-compat只影响go.mod文件头的go x.x声明，不改变实际行为；真正影响兼容性的是你用的 Go 编译器版本 - 唯一建议加参数的场景：脚本批量初始化，且要确保生成的
go.mod有固定内容结构（此时用-modfile+ 重命名更可控）
模块名一旦写进 go.mod，就锁死了整个项目的 import 格局。很多人改完模块名只改了 go.mod，忘了搜遍所有 .go 文件里的 import，结果编译器沉默地跳过错误，直到 runtime 才 panic 找不到包。
