go mod init报“unknown revision”非网络问题，而是因vendor/、Gopkg.lock残留或在GOPATH/src下自动推导module path失败；需清理旧文件、显式指定合法module路径并避免自动推导。
Go 环境搭建早已不是“下载安装包、配 GOPATH、写 hello world”那套流程了——go mod 成为默认依赖管理方式后，环境的核心逻辑已转向模块感知、版本解析与构建缓存协同。你配错的不是路径，而是模块上下文。
go mod 初始化失败：为什么 go mod init 报 “unknown revision”
这不是网络问题，而是当前目录或父级路径里存在未清理的 vendor/ 或残留的 Gopkg.lock（dep 工具遗留），导致 go mod 在自动推导 module path 时误判为旧项目。更隐蔽的是：若当前路径在 $GOPATH/src 下且目录名含点（如 github.com/user/repo），go mod init 会尝试从远程解析该路径对应模块，而此时本地无 go.mod、远程又无对应 tag，就直接报 unknown revision。
- 执行前先确认：
ls -a | grep -E "(vendor|Gopkg|glide)"，删掉旧依赖管理痕迹 - 避免在
$GOPATH/src下初始化新模块；哪怕要用，也显式指定 module 名：go mod init example.com/myapp - 如果目录名天然带点（如克隆的 GitHub 仓库），加
-modfile参数绕过自动推导：go mod init -modfile go.mod.example example.com/myapp
GOPATH 还需要设置吗？什么时候它会被忽略
Go 1.14+ 默认启用模块模式，GOPATH 仅影响三件事：存放 go install 编译出的二进制（到 $GOPATH/bin）、缓存下载的包（到 $GOPATH/pkg/mod）、以及当你用 go get 且没指定版本时，决定往哪放源码（但实际已不推荐这么做）。关键点在于：只要当前目录或任意上级有 go.mod，GOPATH 对代码编译和依赖解析完全无效。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
go build不看GOPATH/src，只认go.mod声明的依赖和本地 replace -
go list -m all显示的模块路径，和GOPATH无关，全由go.mod和replace指令决定 - 唯一还依赖
GOPATH的场景是：你手动go install一个命令，且没加-o指定输出路径——这时它才硬写进$GOPATH/bin
交叉编译失败：GOOS/GOARCH 设了却还是生成 host 平台二进制
常见错因是用了 go run——它不支持跨平台，只运行当前平台可执行文件。go build 才真正响应 GOOS 和 GOARCH。另一个坑是：如果你的代码里调用了 cgo（比如用了 net 包的某些 DNS 解析逻辑），默认会禁用纯静态链接，导致编译出的二进制仍依赖宿主机 libc；此时需额外加 CGO_ENABLED=0。
- 正确命令是：
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -o app-linux-arm64 . - 验证结果：
file app-linux-arm64应显示 “ELF 64-bit LSB executable, ARM aarch64” - 若必须启用 cgo（比如要调系统调用），就得配对应平台的交叉编译工具链（如
aarch64-linux-gnu-gcc）并设CC_aarch64_linux_gnu环境变量
真正卡住人的从来不是命令记不住，而是搞不清哪个环节在读哪个配置、哪个状态覆盖了哪个路径——go env -w 写的变量、当前目录的 go.mod、环境变量、甚至 go.work（多模块工作区）的优先级，差一层就编译出意料之外的结果。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
