go mod init 必须指定模块路径，因其决定 import 解析、依赖拉取和构建一致性；应与未来托管地址一致（如 github.com/username/repo），避免使用本地名、空格或大写字母，并配合 GOPROXY 和 go mod tidy 确保环境一致。
Go 1.16+ 默认启用 Go Modules，GO111MODULE=on 已是事实标准；强行沿用 GOPATH 模式只会触发隐性错误、依赖错乱或 go get 失效。
go mod init 为什么必须指定模块路径？
模块路径不是随便起的名字，它直接影响 import 路径解析和远程依赖拉取。比如执行 go mod init example.com/myapp，后续所有 import "example.com/myapp/utils" 都会按此前缀查找本地包；若你写成 go mod init myapp，则无法正确引用 GitHub 上以 github.com/user/repo 开头的依赖，go get 也会拒绝解析非标准域名路径。
常见错误现象：go: downloading github.com/xxx/yyy v1.2.3 成功，但代码里 import "github.com/xxx/yyy" 却报 cannot find module providing package —— 很可能是因为当前模块路径与 import 路径不匹配，或 go.mod 未生成。
- 模块路径应尽量与未来托管地址一致（如 GitHub 项目就用
github.com/username/repo） - 本地开发可暂用假域名（如
local/myproject），但上线前必须改回真实路径 - 路径中不能含空格、中文或大写字母（Go 规范要求小写 ASCII 字符 + 连字符）
GOPROXY 设置不对，go get 就会卡住或报 403
国内直连 proxy.golang.org 基本不可用，且 Go 1.13+ 默认开启代理，不设 GOPROXY 会导致 go get 超时或返回 no matching versions for query "latest"。
推荐配置（任选其一）：
-
go env -w GOPROXY=https://goproxy.cn,direct（七牛云，稳定、支持私有模块） -
go env -w GOPROXY=https://mirrors.aliyun.com/goproxy/,direct（阿里云镜像） - 若公司有私有仓库，加在
direct前，如https://goproxy.example.com,https://goproxy.cn,direct
direct 表示对私有域名（如 git.internal.company.com）跳过代理直连，否则所有非公开路径都会失败。
go mod tidy 不只是“整理依赖”，它还决定构建一致性
go mod tidy 的本质是：扫描全部 .go 文件中的 import，比对 go.mod，补全缺失依赖、删掉未使用项，并同步更新 go.sum 校验和。它不是可选项，而是 CI/CD 流水线中必须执行的步骤。
容易踩的坑：
- 没运行
go mod tidy就提交代码 →go build在别人机器上失败（缺依赖） - 误删
go.sum后只跑go mod download→ 缺少校验，可能引入被篡改的包 - 多人协作时有人手动改
go.mod→ 必须再跑一遍tidy，否则go.sum与go.mod不一致，go build直接报错
本地 replace 和 require 并存时，优先级很关键
当你用 replace 指向本地路径调试依赖时，go 工具链会完全忽略 require 中声明的版本号——哪怕你写的是 require github.com/foo/bar v1.2.3，只要存在 replace github.com/foo/bar => ../bar，实际编译就用本地 ../bar 的代码。
注意点：
-
replace只在当前模块生效，子模块不会继承 - 上线前必须删掉
replace行，否则打包会漏掉远程依赖 - 若本地路径不存在或
go.mod缺失，go build会直接失败，不 fallback 到require
真正麻烦的不是配置本身，而是不同环境（开发 / CI / 生产）下 go.mod 和 go.sum 的状态是否严格一致 —— 差一个空格、多一行注释，都可能导致构建结果不同。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
