go环境稳定运行需确保模块初始化正确、goos/goarch显式指定、go.mod中go版本声明与团队统一，并清理残留文件；否则易在ci或跨机器时出现构建失败。
Go 环境能跑起来，不等于能稳定、可复现、跨团队协作地用起来。很多看似“装好了”的环境，一到 CI 构建、同事拉代码、或者换台机器就报 go: cannot find main module 或 build constraints exclude all Go files —— 根子往往不在 Go 本身，而在模块初始化时机、GOOS/GOARCH 的隐式继承、或 go.mod 文件里那行被忽略的 go 版本声明。
go mod init 必须在空目录下执行，且不能有残留的 vendor 或旧 go.mod
很多人在已有项目里补加模块支持，直接在根目录跑 go mod init example.com/myapp，结果后续 go build 报错找不到包，或依赖解析错乱。这是因为 go mod init 不会自动扫描现有文件结构，也不会清理历史残留。
- 执行前先确认当前目录是干净的：没有
vendor/、没有旧的go.mod、没有GOPATH风格的src/嵌套结构 - 如果项目已存在但没模块支持，建议新建空目录 →
git clone当前代码进去 → 再go mod init -
go mod init后立即运行go list -m all，看是否列出预期的模块名；若显示command-line-arguments，说明模块未生效，大概率是目录不对或go.mod被写到了子目录
GOOS 和 GOARCH 不写进构建命令，就会继承 shell 环境变量
交叉编译时写 GOOS=linux GOARCH=arm64 go build -o app 看似没问题，但如果你在 macOS 上反复执行，某次忘了重置，GOOS 可能还卡在上次的 windows，导致生成的二进制根本不能运行。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 永远显式指定：哪怕目标和当前一致，也写全
GOOS=linux GOARCH=amd64 go build -o app - 不要依赖
go env -w GOOS=xxx全局设置——它会影响所有后续命令，包括go test和go run - CI 脚本里务必用
env GOOS=xxx GOARCH=xxx go build，避免污染环境变量
go.mod 里的 go 版本声明不是摆设，它决定语法兼容性和内置函数可用性
新建项目时 go mod init 自动生成的 go.mod 里带一行 go 1.21（取决于你本地 Go 版本），但如果团队用的是 Go 1.22，而某人误用了 strings.Clone 这类 1.22+ 新增函数，本地能编译过，CI 却失败——因为 go 1.21 声明让 go build 主动降级检查。
- 初始化后立刻编辑
go.mod，把go行改成团队统一版本，比如go 1.22 - CI 中加一步校验：
grep '^go ' go.mod | grep -q 'go 1\.22' || exit 1 - 升级 Go 版本后，别只改
GOROOT，还要手动更新所有项目的go.mod中的go行，否则旧项目仍按老规则解析
go install 依赖 GOPATH/bin，但模块模式下它只认 $GOBIN，且不自动创建目录
想全局安装一个 CLI 工具如 gopls 或 sqlc，执行 go install github.com/sqlc/sqlc/cmd/sqlc@latest 却提示 command not found，不是权限问题，而是 $GOBIN 目录压根不存在，或没加进 PATH。
- 先确认
go env GOBIN输出路径（默认是$GOPATH/bin，但若设置了GOBIN就以它为准） - 手动创建该目录：
mkdir -p $(go env GOBIN) - 确保该路径已加入
PATH：检查echo $PATH | grep "$(go env GOBIN)" - 注意：
go install在模块模式下不再往$GOPATH/bin写，只写$GOBIN；即使你没设GOBIN，它也会 fallback 到$GOPATH/bin，但这个目录得你自己建好
真正麻烦的从来不是“怎么装”，而是“怎么让所有人、所有机器、所有构建环节都按同一套规则解释同一个 go.mod”。模块版本、构建环境变量、go 声明这三者一旦错位，调试成本远高于重装一遍 Go。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
