GOROOT无需手动设置，GOPATH建议保留并加入PATH；go mod init非强制但强烈推荐；CGO_ENABLED=0非万能，需按目标平台权衡；-o输出路径须确保目录存在且有写权限。
Go 环境搭得不对，go build 会报找不到包、go run 无法执行、交叉编译直接失败——根本不是代码问题，是环境变量或模块模式没对齐。
GOROOT 和 GOPATH 到底要不要手动设？
GOROOT 几乎不用手动设：现代 Go 安装（1.16+）会自动识别安装路径，go env GOROOT 能查到正确值。强行覆盖反而容易出错，比如指向一个不完整的 Go 目录导致 go tool 找不到。
GOPATH 在启用 Go Modules 后已非必需，但仍有两处实际影响：
-
go install命令默认把二进制放到$GOPATH/bin，若没设 GOPATH，它会 fallback 到$HOME/go/bin，但这个路径未必在PATH里，导致命令找不到 - 某些老工具（如
gopls早期版本）或 IDE 插件仍会读取 GOPATH 来定位 stdlib 源码
建议：保留 GOPATH（如 $HOME/go），并确保 $GOPATH/bin 在 PATH 中；GOROOT 不必设，除非你用多版本 Go 管理工具（如 gvm）且需切换。
立即学习“go语言免费学习笔记（深入）”；
go mod init 是必须步骤吗？
不是“必须”，但跳过它大概率导致后续 go build 或 go run 失败，尤其当你 import 第三方包时。
原因在于：GO111MODULE 默认为 auto（1.16+），它只在当前目录或父目录有 go.mod 文件时才启用模块模式；否则回退到 GOPATH 模式——而 GOPATH 模式下，go get 下载的包不会写入任何清单文件，依赖无法复现，CI 构建极易失败。
实操建议：
- 新建项目第一件事就是
go mod init example.com/myapp，模块名不一定要真实域名，但需唯一（避免和标准库冲突） - 如果已有旧项目没
go.mod，直接运行go mod init会自动扫描导入语句生成初始依赖，但注意检查replace或exclude是否被误加 - 禁用模块（
GO111MODULE=off）仅适用于极少数嵌入式场景，日常开发不要碰
交叉编译时 CGO_ENABLED=0 是万能解药吗？
不是。它只是关闭了 CGO，让编译器不链接 C 标准库，从而生成纯静态二进制——但这会砍掉大量依赖 CGO 的功能。
典型牺牲包括：
-
net包的 DNS 解析（回退到纯 Go 实现，可能无法解析某些企业内网域名） -
os/user获取用户名/用户组失败（返回空或 error） - SQLite、PostgreSQL 驱动等基于 cgo 的数据库驱动完全不可用
真正该做的：
- 目标平台明确不需要这些功能（如 Linux CLI 工具），再设
CGO_ENABLED=0 - 若需完整功能，就用对应平台的构建环境（Docker +
golang:alpine或golang:slim）编译，而非强求本地交叉编译 - Windows → Linux 编译时，
CGO_ENABLED=0通常安全；但 Linux → Windows 若用mingw工具链，仍需CGO_ENABLED=1
go build -o 输出路径踩坑最多的地方
-o 参数看似简单，但路径处理极易出错：
- 指定相对路径（如
go build -o bin/app）时，bin/目录必须已存在，否则报no such file or directory，Go 不会自动创建父目录 - 指定绝对路径（如
go build -o /tmp/app）时，确保当前用户对该路径有写权限，否则静默失败（部分旧版 Go 甚至不报错） - 交叉编译时加
-o是允许的，网上流传“不能加”是过时说法（Go 1.10+ 已修复），但要注意输出文件后缀：Windows 目标默认加.exe，Linux/macOS 不加
最稳妥写法：mkdir -p bin && go build -o bin/app .，把路径创建和构建绑在一起，避免 CI 流水线因目录缺失中断。
环境变量、模块初始化、CGO 开关、输出路径——这四点环环相扣，改其中一个，其他地方可能连锁反应。别信“一键配置”，每个项目的真实约束（是否要调系统 API、是否跑在 Alpine、是否要发布到 npm/wasm）决定了哪条路不能绕。
