go version报“command not found”根本原因是path未生效：mac/linux需source ~/.zshrc等配置文件，windows需重启终端并确认path含c:\go\bin。
go version 验证失败：不是“没装”，而是 PATH 没生效
装完 Go 后执行 go version 报 command not found，90% 是 shell 配置没刷新，不是安装失败。Mac/Linux 用户尤其容易忽略 ~/.zshrc 或 ~/.bash_profile 里是否追加了 export PATH=$PATH:/usr/local/go/bin；Windows 用户则要确认系统环境变量里的 Path 是否包含 C:\Go\bin（不是 C:\Go）。
实操建议：
- 先运行
which go（Mac/Linux）或where go（Windows），看有没有输出路径 - 没输出？别急着重装，先执行
source ~/.zshrc（或对应 shell 配置文件） - 仍无效？检查安装路径是否被手动改过——比如 Homebrew 安装的 Go 默认在
/opt/homebrew/bin/go，而非/usr/local/go/bin - Windows 用户注意：修改环境变量后，**必须重启终端**，cmd/powershell 不会自动读取新变量
go mod init 后 go build 失败：vendor 和 GOPROXY 的隐性冲突
新建项目跑 go mod init crawler-pro，接着写几行 http.Get 就想 go build，结果卡在 go: downloading ... 或报 no required module provides package —— 这通常不是代码问题，而是模块代理和本地 vendor 状态打架。
常见诱因：
- 项目目录下存在旧的
vendor/文件夹，但go.mod里没声明go 1.21或更高版本，Go 默认跳过 vendor 直连 proxy -
GOPROXY被设为direct，但你公司内网又没开私有 registry，导致所有依赖拉不到 - 用了
replace指向本地路径，但路径里没有go.mod，Go 拒绝识别为有效模块
快速验证：运行 go env GOPROXY，国内推荐设为 https://goproxy.cn,direct；若需离线编译，先 go mod vendor，再 go build -mod=vendor。
单兵编译产出二进制：-ldflags 的三个关键参数不能漏
所谓“单兵编译”，核心是打出一个无依赖、可直接扔到任意 Linux 服务器上运行的二进制。但默认 go build 出来的文件，可能仍动态链接 libc 或触发 CGO，导致在 Alpine 等精简镜像里直接报 not found。
安全做法是加这组 -ldflags：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
-s：去掉符号表，减小体积（省掉调试信息） -
-w：去掉 DWARF 调试信息（和-s常一起用） -
-buildmode=pie：生成位置无关可执行文件（增强 ASLR 安全性，部分云环境强制要求）
更彻底的静态编译（避开 libc）需额外控制 CGO：
执行前先设 CGO_ENABLED=0，再跑 go build -ldflags="-s -w" -o crawler。注意：一旦禁用 CGO，就无法使用依赖 C 代码的包（如 net 包在某些 DNS 场景下会 fallback 到 libc，此时应改用 netgo 构建标签）。
交叉编译到不同平台：GOOS/GOARCH 组合不是随便填的
想在 macOS 上编译出 Linux 二进制？GOOS=linux go build 看似简单，但实际部署时可能遇到段错误或 syscall 不兼容。根本原因是：GOARCH 必须匹配目标 CPU 架构，且某些组合需要显式指定 CGO_ENABLED=0。
常用可靠组合：
-
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build（通用 x86_64 服务器） -
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build（AWS Graviton / Apple M 系列芯片服务器） -
GOOS=windows GOARCH=amd64 go build（Windows 桌面，CGO 可开，因 Windows API 无 libc 依赖）
容易踩的坑：
-
GOOS=linux GOARCH=386已基本淘汰，现代云服务器极少用 i386，且 Go 1.21+ 对它的支持正在弱化 - 在 macOS 上编译 Windows 二进制，不能用
CGO_ENABLED=1，因为 macOS 没有 Windows 的 C 工具链 - ARM 平台交叉编译时，
GOARM参数仅对GOARCH=arm（非 arm64）有效，填错会导致运行时报illegal instruction
真正麻烦的从来不是命令敲不对，而是编译出来的二进制在目标机器上静默崩溃——它不报错，只是不干活。上线前务必用 file crawler 和 ldd crawler（Linux）或 otool -L（macOS）确认链接状态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
