必须检查go111module=on、goproxy=https://goproxy.cn,direct、gosumdb=sum.golang.google.cn三项变量，缺一不可；运行go env三者命令验证输出是否匹配，否则依赖拉取失败或校验报错。
go env 配置必须检查的三项关键变量
GO111MODULE、GOPROXY 和 GOSUMDB 三项环境变量配置错误，是导致依赖拉取失败、校验报错、模块行为异常的最常见原因。不是“设了就行”，而是要确保值符合当前网络与项目类型。
-
GO111MODULE=on：强制启用 Go Modules，避免go get误入 GOPATH 模式（尤其在旧项目迁移时容易漏掉） -
GOPROXY=https://goproxy.cn,direct：国内首选代理，direct保证私有模块（如公司内网 Git）不走代理；若用https://proxy.golang.org，在国内多数情况会超时或 403 -
GOSUMDB=sum.golang.google.cn：对应 GOPROXY 的校验服务器，不能写成sum.golang.org（国内不可达），否则go build会卡住或报failed to verify module
验证方式：运行 go env GO111MODULE GOPROXY GOSUMDB，三者输出应为上述值。若其中任一为空或错误，用 go env -w 重写，例如：go env -w GOPROXY="https://goproxy.cn,direct"。
交叉编译时 CGO_ENABLED=0 不是万能开关
设置 CGO_ENABLED=0 能生成纯静态二进制，但会禁用所有依赖 C 代码的包——比如 net 包在 Linux 下默认用 cgo 解析 DNS，关掉后可能 fallback 到纯 Go 实现，但某些企业内网 DNS 策略（如 SRV 记录、EDNS）会失效；os/user 在某些发行版上也会无法读取用户信息。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 仅当确认项目不涉及系统级 DNS 查询、不调用
libc相关功能（如unix.Syscall）、且目标环境无 libc 依赖时，才安全使用CGO_ENABLED=0 - 若需保留 cgo 功能但又要控制依赖，改用
CGO_ENABLED=1 GOOS=linux GOARCH=amd64+ Alpine 基础镜像，再通过apk add --no-cache ca-certificates补齐必要库 - 构建前务必测试：在目标环境（如容器或测试服务器）里执行
./your-binary -h或触发一次真实网络请求，而非只看是否生成文件
go.mod 中 replace 和 exclude 容易引发隐性冲突
用 replace 指向本地路径或 fork 分支，或用 exclude 屏蔽某个间接依赖，看似解决版本问题，实则破坏模块一致性。CI 构建、多人协作、甚至 go list -m all 输出都可能因路径差异或缺失 commit 而失败。
-
replace只应在临时调试阶段使用，上线前必须删掉或转为require+ 显式指定 commit hash（如github.com/some/lib v1.2.3-0.20240510123456-abcdef123456） -
exclude本质是“掩耳盗铃”：被 exclude 的模块仍可能被其他依赖间接引入，导致go mod vendor后目录不一致，或 runtime panic 报出未预期的 symbol 冲突 - 真正稳定的解法是统一升级主依赖版本，或用
go mod graph | grep xxx找出冲突源头，针对性require一个兼容版本
VSCode 中 gopls 启动失败常被误判为网络问题
VSCode 的 Go 插件依赖 gopls 提供语言服务，但启动失败往往不是因为代理没配好，而是工作区 go.mod 根路径识别错误，或 GOPATH 与模块路径冲突。
- 打开命令面板（Cmd+Shift+P），运行
Go: Install/Update Tools，勾选gopls单独重装，不要全选——其他工具（如dlv）损坏不会影响代码提示 - 确认 VSCode 打开的是包含
go.mod的**项目根目录**，而不是其子目录；否则gopls无法加载模块，日志里会出现no modules found - 若用
export GOPATH=$HOME/go，确保$HOME/go/src下没有同名模块路径（如github.com/your/project），否则gopls会优先加载 GOPATH 下的旧代码，造成跳转错乱
稳定性不来自“一步到位”，而在于每次 go mod tidy 后验证 go build 是否通过、go test ./... 是否全绿、以及 go list -m all 输出里没有 // indirect 的意外漂移——这些才是环境真正可靠的信号。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
