go 1.22是当前稳定版，但需正确配置go111module=on、goproxy=https://goproxy.cn,direct、cgo_enabled=0，否则易在模块初始化、代理失效或交叉编译到alpine时静默失败。

Go 1.22 是当前稳定版，但直接装完就写代码，大概率会在 go mod、GOPROXY、CGO_ENABLED 这几个地方卡住——不是报错，就是本地能跑、CI 上构建失败、或容器里 panic。

go mod 初始化失败：GOPATH 和 GO111MODULE 混用是主因

常见现象是执行 go mod init 后提示 go: cannot find main module，或者依赖拉不下来，甚至 go list 报错。

• 必须关掉 GOPATH 模式：确保 GO111MODULE=on（不是 auto），否则在 GOPATH 目录下会强制走旧模式
• 项目根目录不能在 $GOPATH/src 下——哪怕设置了 GO111MODULE=on，Go 仍可能降级行为
• go.mod 文件生成后，立刻运行 go mod tidy；如果失败，先确认 GOPROXY 是否生效（go env GOPROXY）

GOPROXY 配置失效：国内镜像源要带 fallback

只设 https://goproxy.cn 看似够用，但遇到私有模块、校验失败或临时不可用时，会直接中断构建，而不是退回到 direct。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

• 正确写法是：GOPROXY=https://goproxy.cn,direct（注意逗号分隔，不是分号）
• 若项目含私有仓库（如 GitHub Enterprise 或 GitLab 私仓），必须加 GOPRIVATE=git.example.com，否则 Go 会跳过代理、直连并失败
• CI 环境中建议显式导出：export GOPROXY=https://goproxy.cn,direct GOPRIVATE=*.corp.com

交叉编译出的二进制在容器里 panic：CGO_ENABLED 被忽略

本地 GOOS=linux GOARCH=amd64 go build 成功，扔进 Alpine 镜像却报 standard_init_linux.go:228: exec user process caused: no such file or directory ——这不是路径错，是动态链接器缺失。

• Alpine 使用 musl libc，而默认 go build 会启用 CGO，链接 glibc，导致不兼容
• 务必加 CGO_ENABLED=0：例如 CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app .
• 如果真要用 CGO（比如调 C 库），就得用 golang:alpine 作 builder，并在 final 阶段安装 musl-dev，但绝大多数 Web 服务完全不需要

Docker 构建时依赖反复下载：没利用好构建缓存

每次 docker build 都重拉一遍依赖，CI 时间翻倍，还容易因网络抖动失败。

• 关键顺序：先 COPY go.mod go.sum .，再 RUN go mod download，最后才 COPY . .
• 避免把 .git 或 node_modules 一起 COPY 进 builder 阶段，会污染 layer 缓存
• 多阶段构建中，builder 阶段的 go mod download 结果不会自动复用到下一阶段，所以必须在 builder 里完成全部构建

真正麻烦的从来不是“怎么装 Go”，而是环境变量之间隐性的相互影响——比如 GO111MODULE 关联 go mod 行为，CGO_ENABLED 决定二进制是否可移植，GOPROXY 的 fallback 机制又和 GOPRIVATE 绑定。漏掉任意一个，都可能让应用在某类环境里静默失败。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！