必须验证Go版本与GOPROXY是否生效、go.mod与go.sum一致性、构建产物跨平台兼容性、并发内存行为，以及执行真实环境验证；每项均需对应命令检查并写入checklist。
审查前先确认 Go 版本与 GOPATH/GOPROXY 是否生效
很多团队在搭建 Go 环境时，表面执行了 go install 或 apt install golang，但实际 go version 输出仍是旧版本，或 go env GOPROXY 返回空值——这意味着模块下载会直连 proxy.golang.org，在国内基本失败。必须验证两点：一是 go version 输出是否匹配预期（如 go1.22.5），二是 go env -w GOPROXY=https://goproxy.cn,direct 是否已写入且生效（运行 go env GOPROXY 应返回该地址）。
常见错误包括：在 Termux 中未设置 $PREFIX/bin 到 $PATH；在 ChromeOS 上用 apt 安装的 Go 未覆盖系统自带低版本；CI 流水线中未显式指定 GOPATH 导致 go build 找不到本地包。
- 检查命令顺序：
which go→go version→go env GOPATH GOPROXY GOMODCACHE - 若
GOPATH为空，Go 1.16+ 默认使用$HOME/go，但 CI 中建议显式设为/tmp/go避免权限问题 -
GOMODCACHE路径需可写，否则go mod download会静默失败
审查 go.mod 文件是否真实反映依赖与兼容性
go.mod 不是“写完就完事”的配置文件。它必须能通过 go mod verify 校验，且所有 require 行不能含 // indirect 标记却无对应 import ——这说明存在未使用的依赖或版本漂移。更关键的是，go.sum 必须存在且与 go.mod 严格匹配，否则 go build 可能拉取不同哈希的包。
典型陷阱：开发者手动编辑 go.mod 添加高版本依赖，但没运行 go mod tidy，导致 go.sum 缺失对应条目；或误删 replace 指令（如指向私有 fork 的路径），使构建在 CI 中失败。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go mod verify，失败则说明校验和不一致 - 运行
go list -m all | grep 'indirect$'，输出非空即表示有未引用的间接依赖 - 检查
replace是否全部被go mod edit -replace命令添加，而非手写——手写易漏掉=>后的版本号
审查构建产物是否满足跨平台与最小化要求
Go 编译出的二进制默认静态链接，但若代码中用了 cgo（比如调用 SQLite 或 OpenSSL），就会依赖系统 libc，导致在 Alpine 或 Termux 中运行失败。审查时必须确认：是否明确禁用 cgo（CGO_ENABLED=0），或是否已适配目标平台的 C 工具链。
另一个常被忽略点是构建标签（build tags）。例如，项目含 //go:build linux 的文件，却在 Windows 开发机上测试，go test ./... 会跳过这部分逻辑，造成覆盖率假象。
- 检查
go build -ldflags="-s -w"是否用于生产构建（去符号、去调试信息） - 确认
GOOS/GOARCH是否在 CI 中显式设定，避免依赖本地环境变量 - 对含
cgo的项目，验证CGO_ENABLED=1时是否安装了对应平台的gcc和头文件（如 Termux 中需pkg install clang）
审查并发与内存行为是否经得起压力验证
Go 环境搭建完成不等于代码安全。很多团队只测功能，不测并发场景下的资源泄漏或 panic。例如，一个用 sync.Pool 缓存对象的模块，若未在 init() 中预热或未控制最大尺寸，压测时可能触发 OOM；又或 context.WithTimeout 被包裹在 goroutine 内部却未传递 cancel 函数，导致 goroutine 泄漏。
这类问题不会在 go build 或单元测试中暴露，必须靠真实负载触发。审查计划里应包含至少一项基于 pprof 的内存/CPU profile 采集步骤，以及用 go tool trace 观察调度延迟。
- 运行
go test -race ./...检查竞态（注意：开启后性能下降，仅限测试环境） - 启动服务后访问
/debug/pprof/heap和/debug/pprof/goroutine?debug=2查看堆分配与 goroutine 数量趋势 - 用
go tool trace分析 GC 停顿时间，尤其关注STW是否超过 10ms
go build 就认为环境 OK，却没验证 go run main.go 是否真能启动服务、是否真能连上数据库、是否真能在目标 OS 上执行。把验证动作写死进 checklist，比写十页文档都管用。 
