答案是path中旧版go路径优先级更高。需运行which go确认实际调用路径，将新版go/bin（如/usr/local/go/bin或/opt/homebrew/opt/go/bin）置入$path最前端，并检查~/.zshrc等配置中是否硬编码goroot，同时vs code用户须同步更新go.goroot设置。
go version 显示旧版本，但已安装新版本？检查 GOROOT 和 PATH 顺序
常见现象：go version 还是 go1.19，而你明明双击安装了 go1.21.11.darwin-arm64.pkg 或用 brew install go 装了最新版。
根本原因不是没装好，而是 shell 找到了另一个 go —— 很可能来自 Homebrew 旧版、手动解压残留、或 VS Code 内置的旧工具链缓存。
- 先查真实路径：
which go，再看它属于谁：ls -l $(which go) - 确认系统级
GOROOT是否被硬编码（尤其在~/.zshrc里写了export GOROOT=/usr/local/go）—— macOS 上官方 pkg 安装后默认GOROOT是/usr/local/go，但 Apple Silicon 机器实际路径可能是/opt/homebrew/Cellar/go/1.21.11/libexec -
PATH中目录顺序决定优先级：把/usr/local/go/bin或/opt/homebrew/opt/go/bin放在$PATH最前面，而不是追加到末尾 - VSCodium / VS Code 用户注意：
Go插件会读取go.gopath和go.goroot设置，即使终端正确，编辑器内go mod仍可能走错路
go mod init 失败提示 “unknown revision” 或超时？GO111MODULE + GOPROXY 必须成对生效
错误典型表现：go mod init example.com/foo 后紧接着 go: downloading golang.org/x/net v0.23.0: unknown revision v0.23.0，或卡在 verifying github.com/... 十几秒不动。
这不是网络抽风，是模块模式未真正启用或代理未穿透所有请求路径。
- 必须同时设置两个环境变量：
GO111MODULE=on（不能是auto） +GOPROXY=https://goproxy.cn,direct（逗号后direct表示私有域名直连，不可省略） - Windows PowerShell 用户别用
set，要用$env:GO111MODULE="on"；macOS/Linux 别只改~/.zshrc，记得source ~/.zshrc，再用go env -w GO111MODULE=on写入全局配置更稳妥 - 公司内网用户：如果用
gitlab.example.com私有仓库，必须补上GOPRIVATE=gitlab.example.com，否则go get仍会尝试走代理并失败 - 验证是否生效：
go env GO111MODULE GOPROXY GOPRIVATE三者都应有值，且无空格或引号
CI 流水线中 go build 报错 “exec: gcc: executable file not found”？交叉编译需显式禁用 cgo
现象：本地 go build 正常，但 GitHub Actions / GitLab CI 的 Ubuntu runner 上失败，报错指向 gcc 缺失。即使你没写 C 代码，某些标准库（如 net、os/user）在 Linux 上默认依赖 cgo。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
这不是要你装 build-essential，而是该关掉它 —— 尤其当你目标只是生成纯静态二进制时。
- 构建命令加前缀：
CGO_ENABLED=0 go build -a -ldflags '-s -w' -o myapp . -
-a强制重编译所有依赖（含标准库），配合CGO_ENABLED=0才能彻底剥离 C 依赖 -
-s -w去除调试符号和 DWARF 信息，体积减少 30%+，且避免泄露构建路径 - 若必须用 cgo（比如调用 SQLite），则 CI 配置里明确安装
gcc和对应头文件：apt-get update && apt-get install -y gcc libc6-dev
本地开发与 CI 编译结果不一致？GOOS/GOARCH 和 Go 版本必须锁定
典型问题：本地 GOOS=linux GOARCH=amd64 go build 出的二进制，在 Docker 容器里 panic；或 GitHub Actions 构建出的镜像启动失败，日志显示 version mismatch。
Go 的二进制不是完全跨平台兼容的 —— 它嵌入了运行时版本号和 ABI 约束，且 GOOS/GOARCH 组合会影响底层 syscall 行为。
- CI 流水线第一行就该固定 Go 版本：
go version输出必须和本地go.mod顶部的go 1.21严格一致；推荐用actions/setup-go@v5并指定go-version: '1.21.11' - 不要只靠
GOOS=linux—— 某些库（如github.com/mattn/go-sqlite3）在GOOS=linux GOARCH=arm64下行为不同，务必在 CI 中复现目标部署环境 - 本地开发建议用
docker run --rm -v $(pwd):/work -w /work golang:1.21.11-alpine go build -o myapp .快速验证是否真能生成可移植二进制 - 最终交付物建议附带构建元数据：
go build -ldflags "-X main.BuildTime=$(date -u +%Y-%m-%dT%H:%M:%SZ) -X main.GoVersion=$(go version)"
最易被忽略的一点：go mod vendor 不等于“离线可用”。vendor 目录只包含 go.sum 里记录的精确哈希版本，但 go build 仍会访问网络校验 checksum —— 若想彻底断网构建，必须配 GOFLAGS="-mod=vendor"，否则 CI 里删了 vendor 目录或换机器仍可能触发下载。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
