必须验证go version≥1.20且go env go111module=on，否则模块行为不可控，导致依赖拉取失败或go mod tidy不生效；goproxy建议设为https://goproxy.cn,direct。
go version 和 GO111MODULE=on 必须验证
本地环境是否真正准备好，不是看能不能跑 hello world，而是看模块行为是否受控。很多“编译失败”或“依赖拉不下来”的问题，根源都在这里。
-
go version输出必须是 1.20+（当前推荐 1.22 或 1.23），低于 1.18 的版本不支持泛型，且viper、opentelemetry-go等主流组件已逐步放弃兼容 -
go env GO111MODULE必须返回on；若为auto，在非 GOPATH 路径下可能意外禁用模块，导致go mod tidy不生效 -
go env GOPROXY建议设为https://goproxy.cn,direct（国内）或https://proxy.golang.org,direct（海外），避免因模块拉取超时中断构建
go build -ldflags="-s -w" 是生产镜像的默认起点
微服务容器镜像越小、启动越快，Kubernetes 调度和扩缩容就越稳。但这个参数组合不是万能的，得知道它干了什么、牺牲了什么。
-
-s去掉符号表，无法用delve远程调试，也丢失 panic 堆栈中的函数名（只剩行号） -
-w去掉 DWARF 调试信息，二进制体积通常减少 20%~40%，但pprof的火焰图会丢失部分函数上下文 - 调试阶段建议用
go build -gcflags="all=-N -l"关闭内联和优化，便于单步；CI 构建流水线里再切回-ldflags="-s -w" - 如果使用多阶段 Dockerfile，第一阶段用完整调试版构建，第二阶段仅 COPY 二进制，
-s -w就足够安全
Docker 构建中 GOCACHE 挂载不是可选，而是必须
本地开发时 GOCACHE 默认启用，但 CI/CD 或 Docker 构建中若不显式挂载，每次都是冷缓存——一个含 50 个依赖的微服务，编译时间可能从 8 秒飙升到 42 秒。
- 在
docker build中通过--mount=type=cache,id=gomod-cache,target=/go/pkg/mod和--mount=type=cache,id=go-build-cache,target=/root/.cache/go-build显式声明缓存 - 若用 GitHub Actions，配合
actions/cache缓存~/.cache/go-build目录，效果等同本地 - 注意：Docker Desktop for Mac 的 volume cache 在某些版本存在 bug，表现为缓存未命中，此时改用
buildkit后端并加DOCKER_BUILDKIT=1环境变量
Makefile 里别直接写 go build，封装成带环境判断的 target
同一个 Makefile 要适配本地开发、CI 构建、K8s 镜像打包三种场景，硬编码 go build 会导致参数混乱或重复维护。
- 定义
BUILD_FLAGS ?= -ldflags="-s -w"，让外部可通过make BUILD_FLAGS="" build覆盖 - 区分
build-dev（含-gcflags="all=-N -l"）和build-prod（默认-ldflags="-s -w"） - 加入
GOOS/GOARCH判断：交叉编译 ARM64 镜像时，make build-prod GOOS=linux GOARCH=arm64 - 避免在
Makefile里拼接长命令，把核心逻辑抽到scripts/build.sh，Makefile只做入口路由
GOCACHE 在容器构建中的显式挂载和 GO111MODULE=on 的强制校验——这两处不落实，后续所有编译优化都打折扣。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
