go版本与模块模式验证第一关是执行go env go111module确认输出为on，检查go.mod首行go版本声明，并运行go list -m验证模块初始化；若输出no modules found则说明未正确初始化或路径错误。
验证 Go 版本与模块模式是否启用
标准化环境的第一关是确认基础运行时状态。很多人以为 go version 输出正常就万事大吉，但实际项目常因 GO111MODULE 未开启而 fallback 到 GOPATH 模式，导致依赖行为不一致。
- 执行
go env GO111MODULE，输出必须是on；若为auto或空，需显式设置export GO111MODULE=on - 检查项目根目录是否存在
go.mod文件，且首行含go 1.21（或你锁定的版本），这是模块兼容性锚点 - 运行
go list -m，应列出当前模块及所有直接依赖；若报错no modules found，说明模块未初始化或路径错误
用 go test ./ 验证测试可发现性与包隔离
Go 的测试机制强依赖目录结构和包声明。测试文件放错位置、包名不匹配，会导致 go test ./ 完全跳过该目录，但又不报错——这是最隐蔽的“伪通过”。
- 确保每个子包（如
auth/、http/）下有*_test.go文件，且其package声明与源码包名完全一致（例如源码是package auth，测试文件也必须是package auth，不是auth_test） - 禁止创建统一的
tests/目录存放所有测试——这会破坏包内访问权限，迫使你暴露内部函数，还让go test ./找不到测试 - 在项目根目录运行
go test ./...（注意三点），观察是否递归进入所有子目录；若某目录无输出，大概率是包名或文件后缀错了
检查 gofmt、golint、go vet 是否能本地触发
格式与静态检查工具若只在 CI 里跑，等于没集成。开发者提交前没感知，问题就会堆积到流水线再爆，拖慢反馈周期。
-
gofmt -s -w .应能无报错重写全部.go文件；若提示exit status 1，常见原因是文件权限不足或编辑器锁住了文件 -
go vet ./...必须零警告；典型漏网错误包括：结构体字段标签拼写错误（如json:"name"写成josn:"name"）、defer后接未求值函数调用 - 如果用
golangci-lint，运行golangci-lint run --fast；首次失败往往是因为.golangci.yml中启用了未安装的 linter（如revive），需先go install github.com/mgechev/revive@latest
Docker 构建阶段能否复现本地 go build 行为
容器镜像里的构建结果和本地不一致？通常不是 Dockerfile 写错了，而是忽略了构建上下文差异。
- Dockerfile 第一行必须是
FROM golang:1.21-alpine（版本号需与本地go version严格一致），Alpine 镜像默认不带git，若go mod download依赖私有仓库，得加RUN apk add --no-cache git -
COPY . .前应先COPY go.mod go.sum .并RUN go mod download，否则每次构建都重新拉依赖，且可能因网络波动失败 - 构建命令用
RUN go build -o /app/main .，而非go build -o main ./cmd/app—— 后者依赖特定目录结构，一旦main.go不在cmd/app下就静默失败
真正容易被忽略的是：Docker 构建时没有加载用户 shell 配置（如 .zshrc 中的 GO111MODULE=on），所以必须在 Dockerfile 里显式设环境变量，或依赖官方镜像默认已开启。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
