go mod init 不是万能钥匙，仅生成 go.mod 文件，需在项目根目录用真实远程路径（如 github.com/you/myapp）初始化，确保模块路径与所有 import 语句完全匹配，并立即执行 go mod tidy 补全依赖和生成 go.sum。
go mod init 不是创建项目的万能钥匙，它只生成 go.mod 文件，不帮你建目录、不初始化 Git、也不自动识别已有代码的模块路径——乱用会导致 import 路径错乱、依赖拉取失败、CI 构建报 no required module provides package。
go mod init 后 import 路径和实际目录对不上怎么办
这是最常踩的坑：你在 ~/projects/myapp 下执行 go mod init myapp，但代码里写了 import "github.com/you/myapp"，Go 就会找不到包——因为模块路径（myapp）和 import 路径（github.com/you/myapp）不一致。
- 模块路径必须和所有
import语句开头完全匹配，包括协议前缀（如github.com/） - 如果项目将来要公开或推送到 GitHub，初始化时就该用真实远程路径：
go mod init github.com/you/myapp - 本地开发暂不托管？可用任意合法域名占位，比如
go mod init example.com/myapp，只要全项目 import 统一即可 - 改过
go.mod里的module行后，记得批量替换所有import——编辑器全局替换比手动修安全
go mod init 在子目录下执行会出什么问题
在项目中间某个子目录（比如 cmd/api）里随手敲 go mod init api，结果生成的 go.mod 只管这个子目录，上层 main.go 或 internal/ 包全被当成“未声明模块”，运行时报 cannot load internal/xxx: cannot find module providing package。
-
go mod init必须在项目根目录执行，且该目录应包含main.go或最高层import入口 - Go 没有“多模块子项目”概念（除非显式用
replace或workspace），一个 repo 通常只对应一个go.mod - 如果真要拆模块（如
lib/独立发版），得把lib/提成独立仓库，再用replace临时链接本地路径
go mod init 后 go build 报 missing go.sum 或 indirect 依赖混乱
go mod init 只写 go.mod，不下载依赖、不生成 go.sum、也不分析现有代码引入了哪些包——所以直接 go build 很可能失败。
- 执行完
go mod init后，立刻跑go mod tidy：它会扫描所有.go文件，补全依赖、写入go.sum、清理未用项 - 别信
go get xxx能代替tidy；手动get容易漏间接依赖，且可能拉错版本 - 如果代码里用了
_ "net/http/pprof"这类空白导入，tidy会把它当真实依赖保留——这是对的，别删 - CI 环境务必用
GO111MODULE=on go mod download预热缓存，否则tidy可能超时
模块路径一旦写进 go.mod 并被其他项目 import，就基本锁死了；改名等于发布新模块。很多人以为重命名目录 + 改 go.mod 就行，其实所有下游 import 语句、CI 脚本、Dockerfile COPY 路径都得同步动——这点最容易被忽略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
