go install 默认将二进制文件放入 $GOBIN（若已设置且可写），否则放入 $GOPATH/bin 的第一个路径；它按 import path 解析而非当前目录，且在 module 模式下支持远程模块安装。
go install 会把编译后的二进制文件放到哪里？
go install 默认把可执行文件放进 $GOPATH/bin（Go 1.18 之前）或 $GOBIN（如果设置了），否则 fallback 到 $GOPATH/bin。它**不关心当前目录是否在 $GOPATH/src 下**，只要能解析 import path 就行。
- Go 1.16+ 默认启用 module 模式，
go install支持直接安装远程模块（如go install github.com/rogpeppe/godef@latest），此时根本不需要 GOPATH - 如果项目还在 GOPATH 模式下（即没有
go.mod），且你运行go install时在$GOPATH/src/foo/bar目录里，它会尝试安装foo/bar对应的 main 包 - 没设
$GOBIN且$GOPATH有多个路径？只有第一个$GOPATH的bin/会被使用
为什么 go install 报错 “no Go files in …”？
这是最常遇到的卡点：你进了某个目录，敲了 go install，结果提示找不到 main 包或 Go 文件。根本原因不是路径不对，而是 go install 默认按 **import path** 工作，不是按当前目录。
- 如果你在项目根目录，但没
go.mod，且该目录不在$GOPATH/src下 →go install根本不会识别它是一个可安装包 - 有
go.mod但没main函数？报错是no buildable Go source files或类似提示 - 想强制安装当前目录下的 main 包？用
go install ./...（注意末尾的...）或更精准的go install . - Go 1.21+ 对
go install .做了限制：只允许当前目录含main包，否则报错；以前版本可能静默失败
go install 和 go build + 手动复制有啥实际区别？
区别主要在**路径管理、模块版本绑定和环境一致性**上，不是“能不能跑”的问题，而是“下次还能不能复现这个二进制”的问题。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
go build -o $GOPATH/bin/mytool .生成的二进制不记录依赖版本；go install ./...@v1.2.3会锁定所有 transitive 依赖，保证可重现 - 没加
@version时，go install默认用go.mod中的require版本；而go build只看当前go.mod+go.sum，不涉及全局 module cache 状态 - 如果项目用了 replace 或 exclude，
go install会遵守，但go build在某些 GOPATH 模式下可能绕过 -
go install生成的二进制默认 strip 符号表（比go build -ldflags="-s -w"更省事）
GOBIN 和 GOPATH/bin 冲突时以谁为准？
$GOBIN 优先级永远高于 $GOPATH/bin —— 只要它被设置了且路径可写，go install 就不会碰 $GOPATH/bin。
立即学习“go语言免费学习笔记（深入）”；
- 检查方式很简单：
echo $GOBIN；为空就走$GOPATH/bin（取第一个$GOPATH） - 常见陷阱：你在 shell 里 export 了
GOBIN，但用sudo go install→ sudo 会重置环境变量，导致二进制被装到 root 的$GOPATH/bin，普通用户执行不了 - Windows 用户注意：
%GOBIN%必须是正斜杠或双反斜杠路径，单反斜杠可能被忽略（比如C:\bin会被跳过） - 如果你删了
$GOBIN目录但忘了 unset 变量，go install会静默失败（不报错，也不生成文件）
事情说清了就结束。真正容易被忽略的是：go install 的行为在 module 模式和 GOPATH 模式下逻辑完全不同，而很多人还拿着老教程去套新版本，卡在 import path 解析那一步就停了。
