go mod init 未生成 go.mod 是因未在含 .go 文件的项目根目录执行，且需清理 vendor/ 等干扰项；模块路径应按托管地址或反写域名规范填写，init 不下载依赖，需后续 go mod tidy 补全。
go mod init 后为什么找不到 go.mod 文件
执行 go mod init 没反应，或者当前目录没生成 go.mod，大概率是因为你没在空目录或已有 Go 代码的根目录下运行。它不会自动递归找 .go 文件，只看当前路径有没有可识别的包结构。
- 必须在项目根目录执行，且该目录下至少有一个
.go文件（哪怕只是空的main.go） - 如果当前目录有
vendor/或旧的Gopkg.lock，可能被误判为非模块环境，先清理再试 - 别在
$GOPATH/src下直接 init —— Go 1.13+ 默认开启模块模式，但路径冲突会导致静默失败
module 名字填什么才不踩坑
go mod init 后面跟的参数不是随便起的项目名，而是模块路径（module path），它会直接影响 import 语句和依赖解析逻辑。填错会导致后续 go get 失败、IDE 无法跳转、CI 构建拉不到私有库。
- 公开项目：用代码托管地址，比如
go mod init github.com/username/project - 内部项目：建议用公司域名反写 + 路径，如
go mod init internal.company.com/backend/api，避免用localhost或127.0.0.1 - 本地调试临时用：可以填任意合法标识符（如
go mod init demo），但上线前必须改，否则别人import "demo"根本 resolve 不到
go mod init 会自动下载依赖吗
不会。go mod init 只生成最简 go.mod，里面只有 module 和 go 版本声明，不触碰网络，也不分析现有代码里的 import。
- 想补全依赖列表，得紧接着跑
go mod tidy—— 它才会读所有.go文件、拉取缺失模块、删掉未用依赖 - 如果代码里 import 了尚未
go get过的包（比如"golang.org/x/sync/errgroup"），go mod tidy才会去 fetch - 注意：
go mod tidy在 GOPROXY=direct 且无外网时会卡住，提前设好代理更稳
初始化后 go build 报错 “cannot find module providing package”
典型现象是编译时提示找不到某个 import 的路径，比如 cannot find module providing package github.com/sirupsen/logrus，说明模块感知到了 import，但本地缓存或 go.mod 里没记录它。
- 不是
go mod init没用好，而是后续没同步依赖 —— 立刻执行go mod tidy - 如果用了 replace 或 exclude，在
go.mod里手动删掉再 tidy，否则可能绕过真实依赖 - 检查
GO111MODULE环境变量是否为on（推荐显式设置，避免受当前路径是否在 GOPATH 影响）
go.mod，就绑定到所有 import 语句里；改名字不是改一行的事，得全局替换 import 路径、更新 CI 配置、通知协作者——所以 init 那一刻，就得想清楚。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
