Go环境配置核心是go命令可用、依赖可解析、二进制跨平台可运行；需确保PATH包含Go bin路径、新项目用go mod init初始化、跨平台构建须显式设GOOS/GOARCH。
Go 项目构建环境配置的核心问题不是“装没装 Go”，而是 go 命令能否被识别、go build 能否正确解析依赖、生成可执行文件是否能在目标平台运行。只要这三点成立，环境就算配好了；其余配置（如 GOPATH、IDE 插件）只是锦上添花。
确认 go 命令在终端中可用
这是最常卡住的第一步。很多人安装了 Go，但终端里敲 go version 报错 command not found，本质是 /usr/local/go/bin（或你实际安装路径下的 bin）没进 PATH。
- 先查 Go 安装位置：
ls -la /usr/local/go/bin/，看到go和gofmt就说明二进制已存在 - 再检查当前
PATH：echo $PATH，确认输出里包含/usr/local/go/bin - 如果没包含，追加到 shell 配置文件（如
~/.zshrc或~/.bash_profile）：export PATH=$PATH:/usr/local/go/bin - 重载配置：
source ~/.zshrc，再试go version
注意：不要用 which go 判断——某些系统会缓存结果；务必用 go version 实际触发命令。
区分 GOPATH 模式与 Go Modules 模式
Go 1.11 引入 go mod 后，GOPATH 已非必需。现在绝大多数新项目应直接使用 Modules，否则容易出现 cannot find module providing package 或依赖拉取失败。
立即学习“go语言免费学习笔记（深入）”；
- 新建项目时，先进入空目录，运行
go mod init example.com/myapp，自动生成go.mod - 之后所有
go build、go run都基于go.mod解析依赖，不再读取GOPATH/src -
GOPATH仅在以下情况仍需关注：维护老项目、使用某些旧工具（如gocode）、或需要把go install的二进制放到$GOPATH/bin下 - 若真要设
GOPATH，建议只设一个路径（如$HOME/go），避免多路径导致go list行为异常
构建跨平台二进制前必须设置 GOOS 和 GOARCH
Go 编译默认产出当前系统的可执行文件。想编译 Linux 版本给服务器跑，却在 macOS 上直接 go build，结果得到的是 macOS 二进制——扔到 Linux 上根本无法执行。
- 编译 Linux 服务端程序：
GOOS=linux GOARCH=amd64 go build -o myapp - 编译 ARM64 服务器（如树莓派）：
GOOS=linux GOARCH=arm64 go build -o myapp - Windows 客户端：
GOOS=windows GOARCH=amd64 go build -o myapp.exe -
GOOS可选值包括linux、darwin、windows、freebsd；GOARCH常见为amd64、arm64、386
这个步骤不能省，也没有“一次编译、到处运行”的捷径——Go 的静态链接特性意味着每个目标平台都需要单独构建。
go build 输出体积大？别急着加 -ldflags
新用户常发现 go build 出来的二进制动辄 10MB+，以为是没优化。其实这是 Go 默认包含调试符号和 DWARF 信息的结果，不影响运行，但部署时可裁剪。
- 减小体积（去掉调试信息）：
go build -ldflags="-s -w" -o myapp -
-s去除符号表，-w去除 DWARF 调试信息 - 注意：加了这两个 flag 后，
pprof、delve等调试工具将无法使用——仅建议用于生产部署包 - 真正影响体积的不是 flag，而是导入的包。比如用了
net/http/pprof或大型 ORM，体积增长主要来自它们
构建环境配置中最容易被忽略的，其实是 GOOS/GOARCH 的显式声明和 go mod 的初始化时机——这两点一旦出错，后续所有构建行为都会偏离预期，但错误提示往往不直接指向根源。
