go install 与 go build 的核心区别在于输出路径和用途：go build 默认生成可执行文件到当前目录，用于快速验证；go install 则强制输出到 $gobin（或 $gopath/bin），要求 package main，本质是安装命令行工具。
go build 和 go install 的行为差异在哪
区别不在功能强弱，而在输出路径和用途定位。go build 默认把可执行文件生成在当前目录，适合快速验证；go install 则强制输出到 $GOBIN（若未设置则为 $GOPATH/bin），且要求 package main + func main()，本质是“安装一个命令行工具”。
容易踩的坑：
-
go install不会自动创建$GOBIN目录，目录不存在时静默失败，无任何提示 - Go 1.16+ 默认启用 module 模式，
go install若在 module 外执行（即无go.mod），会报错go install: no modules specified - 想用
go install安装本地项目，必须先go mod init example.com/cmd，再确保main.go在根目录或cmd/xxx下
为什么 GOPATH 在 Go 1.16+ 里好像“失效”了
不是失效，而是角色降级。Go 1.11 引入 module 后，依赖管理不再依赖 GOPATH/src 的路径结构；Go 1.16 起彻底取消对 GOPATH 的隐式依赖——go run、go build 均可脱离 GOPATH 工作。
但 GOPATH 仍有实际作用：
-
go get（旧模式）仍会把包下载到$GOPATH/pkg/mod（module 缓存实际走的是$GOMODCACHE，默认值为$GOPATH/pkg/mod） -
go install若未设GOBIN，仍 fallback 到$GOPATH/bin - 某些老 IDE 或脚本仍硬编码读取
GOPATH来定位 src 或 bin
建议：保留 GOPATH（如 ~/go），但不要把它当作项目根目录来组织代码——新建项目直接 mkdir myapp && cd myapp && go mod init myapp 即可。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
从源码编译 Go 编译器要绕开哪些硬坑
自举编译（即用旧版 Go 编译新版 Go 源码）不是常规开发需求，但排查底层问题或调试 runtime 时可能遇到。关键点不在“能不能”，而在“怎么避免卡死”：
- 必须设置
GOROOT_BOOTSTRAP，指向一个可用的、版本 ≥ 当前源码要求的 Go 安装路径，例如export GOROOT_BOOTSTRAP=/usr/local/go - 不要在
$GOROOT/src外 clone 源码；官方要求源码必须放在$GOROOT/src，否则./all.bash会找不到标准库路径 -
./all.bash包含完整测试，Mac M 系列或老旧笔记本大概率因 timeout 失败（尤其是os/signal、net/http相关测试），此时改用./make.bash可跳过测试只编译 - 编译后需手动调整
PATH：把新生成的$GOROOT/bin放在旧版之前，否则go version仍显示旧版本
go env 输出里 GOROOT 和 GOPATH 的真实含义
GOROOT 是 Go 安装根目录，即编译器、标准库、工具链（go、compile、link 等）所在位置；GOPATH 是用户级工作区，影响 go install 输出位置和旧式依赖存放逻辑。两者不重叠，也不应重叠。
典型错误配置：
- 把
GOPATH设成/usr/local/go（即和GOROOT相同）→go install会尝试往系统目录写入，权限失败 - 未设
GOROOT却手动把go二进制软链到/usr/local/bin/go→go env GOROOT返回空，后续go tool compile找不到runtime包路径 - 在 WSL 或 Docker 中运行
go，GOROOT被识别为 Windows 路径（如C:\Go）→ 编译直接报cannot find package "runtime"
最稳妥做法：安装时用官方 MSI/DMG 包（自动配好 GOROOT），GOPATH 单独设为用户目录（如 ~/go），全程不手动修改 GOROOT。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
