不依赖 GOPATH，但必须有正确的 GOROOT；Go 1.16+ 默认启用模块模式，go build 和 go run 仅依赖 go.mod 文件及 GOROOT 指向的标准库和编译器，GOROOT 错误会导致 failed to load package runtime 等底层错误。
go build 和 go run 都依赖 GOROOT 和 GOPATH 吗？
不依赖 GOPATH，但必须有正确的 GOROOT。从 Go 1.16 开始，模块模式（go mod）成为默认，GOPATH 不再参与构建逻辑——go build 和 go run 只认当前目录下是否有 go.mod，然后从该文件解析依赖路径。但 GOROOT 始终关键：它指向 Go 标准库和编译器本体，缺失或错误会导致 go: cannot find main module 或更底层的 failed to load package runtime 错误。
-
GOROOT必须指向真实安装目录（如/usr/local/go或C:\Go），且$GOROOT/bin要在PATH中 - 若未初始化模块，
go run main.go仍能运行单文件，但不会下载依赖；一旦 import 第三方包，就会报no required module provides package -
go env GOPATH输出值现在仅影响go install（无-mod=mod时）和旧式src/pkg/bin目录布局，日常构建几乎不用
为什么 go run 能直接执行，而 go build 生成的二进制却不能跨系统运行？
go run 是“编译 + 立即执行”的快捷封装，它调用的是本地 GOROOT 下的 gc 编译器，目标平台就是当前机器（GOOS/GOARCH 默认继承自运行环境）。go build 默认也如此——它生成的可执行文件天然绑定当前系统，不是“跨平台”而是“同构编译”。真正决定能否跨系统运行的是显式设置的构建目标：
-
go build -o hello-linux main.go→ 仍在当前系统生成 Linux 二进制（可能失败，如 Windows 上构建 Linux 需 CGO_ENABLED=0） -
GOOS=linux GOARCH=arm64 go build -o hello-arm64 main.go→ 交叉编译，生成 Linux ARM64 二进制，可在对应机器直接运行 - 若代码用了
cgo（比如调用 C 库），交叉编译需匹配目标平台的 C 工具链，否则会报cannot use cgo with cross compilation
go mod init 后，go run 仍然报错找不到包，常见原因有哪些？
模块初始化只是创建 go.mod 文件，不自动解决导入路径问题。最常踩的坑是：包名与文件路径、模块路径不一致，或未正确声明 package main。
- 执行
go mod init example.com/hello后，所有import语句必须按该模块路径引用子包，比如import "example.com/hello/utils"，而非import "./utils" -
main.go必须位于模块根目录（即go.mod所在目录），且首行必须是package main；若放在cmd/app/main.go，需确保go.mod在上层，且go run cmd/app/main.go显式指定路径 - 第三方包未下载：运行
go mod tidy自动拉取并写入go.mod和go.sum，否则go run会卡在 “missing required module”
验证环境是否真就绪，只靠 go version 够吗？
不够。go version 只确认 go 命令可达，但无法反映模块支持、网络代理、标准库完整性等实际运行条件。
立即学习“go语言免费学习笔记（深入）”；
- 加测：
go env GOROOT GOPATH GOOS GOARCH—— 确保GOROOT非空且路径存在，GOOS/GOARCH与预期一致 - 加测：
go list std—— 列出所有标准库包，若报错cannot load runtime: cannot find module providing package runtime，说明GOROOT损坏或被覆盖 - 加测：
go run -（输入package main; import "fmt"; func main(){fmt.Println("ok")}后 Ctrl+D）—— 实际触发一次完整编译+执行链，比go version更贴近真实场景
GOROOT 的隐性污染：比如手动把另一个版本的 Go 解压到 /usr/local/go 但没清空旧 bin 目录，导致 go version 显示新版本，而 go run 调用的却是旧编译器，引发奇怪的语法错误或 panic。动手前先 ls -l $(which go) 和 readlink -f $(which go) 确认真实路径。 
