必须区分，且不能混用。GOROOT指向Go安装根目录（如D:\go），是编译器、go命令所在位置；GOPATH是用户工作区路径（如D:\go_work），存放src、pkg、bin；Go 1.11+启用模块后项目可脱离GOPATH，但go install仍默认输出到$GOPATH/bin。
Go 环境变量配置必须区分 GOROOT 和 GOPATH 吗？
必须区分，且不能混用。GOROOT 指向 Go 安装根目录（如 D:\go），是编译器、go 命令本身所在位置；GOPATH 是用户工作区路径（如 D:\go_work），存放 src、pkg、bin。从 Go 1.11 起启用模块（GO111MODULE=on）后，src 下的项目可脱离 GOPATH，但 go install 仍默认把可执行文件写入 $GOPATH/bin（除非显式设置 GOBIN）。
常见错误现象：go: cannot find main module 或 command not found，往往是因为：
-
GOROOT未设或指向错误目录（比如指向了go_work） -
PATH中漏加%GOROOT%\bin，导致命令行找不到go -
GOPATH目录下缺少src子目录，而你又在非模块模式下运行go build
为什么 go build 生成的二进制文件能直接运行，不依赖 DLL 或.so？
因为 Go 默认静态链接所有依赖（包括标准库和 runtime），最终产物是自包含的机器码文件。它只依赖操作系统内核提供的系统调用接口（如 read、write、mmap），不依赖 libc（Windows 下不依赖 msvcrt.dll，Linux 下不依赖 glibc）。
这个行为受两个关键参数控制：
立即学习“go语言免费学习笔记（深入）”；
-
-ldflags="-s -w"：剥离调试符号和 DWARF 信息，减小体积 -
-ldflags="-linkmode external"：强制使用外部链接器（如 gcc），此时可能引入 libc 依赖（仅限特定场景，如 cgo 启用时）
注意：一旦代码中 import "C" 并调用 C 函数，就触发 cgo，链接行为变为动态——此时 go build 生成的文件会依赖目标平台的 C 运行时（Windows 下是 msvcrt.dll，Linux 下是 libc.so.6）。
跨平台交叉编译时，GOOS 和 GOARCH 怎么选才不出错？
Go 原生支持交叉编译，无需安装额外工具链。关键不是“能不能”，而是“是否启用 cgo”。只要没调用 C 代码，GOOS 和 GOARCH 可自由组合；一旦启用 cgo，就必须匹配目标平台的 C 工具链（例如 Windows 上交叉编译 Linux ARM64 二进制，需提前装好 aarch64-linux-gnu-gcc）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
常用组合示例：
- Windows 上构建 macOS 二进制：
GOOS=darwin GOARCH=amd64 go build - Linux 上构建 Windows 32 位程序：
GOOS=windows GOARCH=386 go build - macOS 上构建 Linux ARM64：
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build（必须关 cgo）
容易踩的坑：CGO_ENABLED=1 时，GOOS/GOARCH 改变会导致 gcc 找不到对应头文件或库，报错类似 fatal error: stdio.h: No such file or directory。
go run 和 go build 的本质区别在哪？
go run 是“编译 + 运行 + 清理临时文件”的快捷封装；go build 只编译，输出可执行文件。两者都调用同一套编译器（gc），但生命周期不同。
关键差异点：
-
go run main.go会在$TMPDIR下生成临时可执行文件，运行完自动删除；不适合调试崩溃堆栈（因为文件已删） -
go build -o app main.go输出明确路径的二进制，可反复执行、分发、用gdb调试 - 若项目含多个
.go文件，go run必须列出全部（go run *.go或go run ./...），否则报undefined: xxx
性能上无实质差别——都是调用 gc 编译器，只是 go run 多了一次进程 fork 和临时文件 I/O。真正影响启动速度的是 runtime 初始化和 GC 启动开销，而非命令本身。
最常被忽略的点：模块初始化时机。go run 在每次执行时都会重新解析 go.mod 并下载缺失依赖（除非已缓存），而 go build 同样如此；但如果你用 go install 安装到 GOBIN，后续调用该命令时不会重复解析模块——这点在 CI/CD 流水线里容易引发隐性延迟。
