Go环境搭建核心是模块初始化、工具链复现和静态二进制交付：必须启用GO111MODULE=on，用go install手动安装gopls/dlv并配GOPROXY，生产编译需CGO_ENABLED=0交叉编译，且每次go mod tidy后须执行go mod verify校验go.sum。
Go 环境搭建不是“装完 go version 能跑就行”，关键在三件事：模块初始化不踩坑、工具链可复现、二进制交付能直接扔进生产服务器跑起来。其他都是枝节。
go env 配置必须关掉 GO111MODULE=off
很多报错如 cannot find module providing package 或 main module not found，根源就是环境变量里留着 GO111MODULE=off。Go 1.16+ 默认开启 Modules，硬关它等于退回到 GOPATH 黑暗时代。
- 检查当前值：
go env GO111MODULE，输出应为on或空（空 = 默认 on） - 若为
off，执行：go env -w GO111MODULE=on - 顺手清理旧残留：
unset GOPATH（仅临时），或从~/.zshrc中删掉显式设置GOPATH的行——模块项目根本不需要它 - 注意：某些老脚本或 CI 配置里可能硬编码了
GO111MODULE=off，得一并改掉
gopls 和 dlv 必须用 go install 安装，不能靠 IDE 自动拉
VS Code 或 GoLand 提示 “Install tools” 时点全部安装，看似省事，实则极大概率失败：网络超时、版本错配、权限冲突。IDE 不知道你设了代理，也不管你用的是哪个 Go 版本。
- 手动安装才是可控路径：
go install golang.org/x/tools/gopls@latest和go install github.com/go-delve/delve/cmd/dlv@latest - 装完立刻验证：
which gopls和which dlv应输出类似$HOME/go/bin/gopls - 国内用户必加代理：
go env -w GOPROXY=https://goproxy.cn,direct，否则@latest会卡死 - 如果
dlv调试断点不命中，先确认dlv version输出的 Go 版本 ≥ 当前项目所用 Go 版本
生产级编译必须交叉编译 + 静态剥离
本地 go build 出来的二进制，直接 scp 到 CentOS 或 Ubuntu 生产机上跑，十有八九报 not found——不是找不到文件，是动态链接器找不到 libc 兼容版本。这不是 bug，是默认行为。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 正确做法（Linux 服务端通用）：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o ./bin/app . -
CGO_ENABLED=0：禁用 C 调用，生成纯静态二进制，无系统依赖 -
-ldflags="-s -w"：去掉符号表和调试信息，体积缩小 30%～50%，且无法被strings反查敏感字符串 - 别信
go build -o app能直接上线；也别用 Docker 镜像编译来“绕过”——那只是把问题藏得更深
go mod tidy 后必须验证 go.sum 未被篡改
go mod tidy 看似只是拉依赖，但它会修改 go.sum。而这个文件一旦被意外覆盖或提交错误哈希，CI 构建就可能拉到恶意包，且毫无提示。
- 每次
go mod tidy后，运行：go mod verify—— 它会校验所有模块哈希是否匹配go.sum - CI 流水线中必须加入这步，失败即中断：
if ! go mod verify; then echo "go.sum mismatch!"; exit 1; fi - 禁止手动编辑
go.sum；也不要在不同 Go 版本间混用同一份go.sum（不同版本计算方式微调） - 团队协作时，
go.sum必须提交进 Git —— 它不是“中间产物”，而是依赖指纹清单
最常被跳过的其实是 go mod verify 这一步。它不报错，没人记得加；但它一旦漏掉，上线那一刻就可能变成供应链攻击入口。
