go test 在 gitlab ci 中不失败的根本原因是默认不启用失败退出机制——即使发生 panic，若未调用 t.fatal/t.error，go test 仍可能返回 0；须用 go test -v -failfast -race ./... 确保失败时非零退出码。
Go test 命令在 .gitlab-ci.yml 里为什么总不失败？
GitLab CI 跑 go test 后显示 “PASS” 却没拦住有 panic 或未覆盖的错误，根本原因是默认不启用失败退出机制——只要测试函数没显式调用 t.Fatal 或 t.Error，哪怕 panic 发生，go test 仍可能返回 0（成功状态）。
- 必须加
-v（看输出） +-failfast（快速暴露首个失败） - CI 中建议统一用
go test -v -failfast -race ./...：开启竞态检测能提前暴露 goroutine bug，且-race本身会让失败测试强制返回非零码 - 避免只测单个包如
go test ./cmd，漏掉./internal下的逻辑；用./...才覆盖全部可测试路径 - 如果项目用了
testmain自定义入口，需确认其os.Exit()调用逻辑是否被 CI shell 截断——GitLab Runner 默认用sh，某些 exit 码可能被忽略，改用bash并显式检查$?
.gitlab-ci.yml 里 go build 失败但没报错？
go build 在 CI 中静默失败，常见于 GOPATH / module 混用、CGO_ENABLED 不一致或交叉编译目标缺失。GitLab Runner 默认环境往往没预装完整 Go 工具链，也缺少 libc 头文件。
- 务必在
before_script中运行go env -w GOPROXY=https://proxy.golang.org,direct，避免私有模块拉取超时导致构建卡死 - 禁用 CGO（除非真需要 C 依赖）：
CGO_ENABLED=0 go build -o bin/app ./cmd/app，否则 Alpine 镜像里会因缺musl-dev直接报gcc: command not found - 交叉编译注意
GOOS和GOARCH必须显式指定，比如部署到 ARM64 服务器却只写go build，默认产出仍是 amd64 可执行文件 - 别信
go build -o /dev/null这种“只检查语法”的写法——它跳过链接阶段，无法发现符号未定义、import 循环等真实问题
发布二进制到 GitLab Package Registry 总是 401？
上传 go build 出来的二进制到 GitLab Package Registry 报 401 Unauthorized，不是 token 权限不够，而是请求头没带认证、URL 路径拼错，或项目 visibility 设置为 private 但 token 没 scope。
- 必须用
curl -H "JOB-TOKEN: $CI_JOB_TOKEN"（不是PRIVATE-TOKEN），且$CI_JOB_TOKEN仅在 job 内有效，不能存成变量复用 - 上传 URL 格式严格为：
https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/packages/generic/$PACKAGE_NAME/$PACKAGE_VERSION/binary，其中$PACKAGE_NAME不能含斜杠或大写字母，否则 400 先于 401 报出 - GitLab Free 版只支持 generic packages，别试图传
deb或npm包——即使 URL 对，也会返回 404 - 上传前先用
file ./bin/app确认二进制架构匹配目标平台，否则下游用户下载后exec format error才发现白忙活
Go mod vendor 在 CI 中要不要用？
用 go mod vendor 本质是把依赖快照进代码库，换来构建确定性，但代价是体积膨胀、diff 冗余、以及 vendor 目录权限/换行符在 Windows/Linux 间容易出问题。
立即学习“go语言免费学习笔记（深入）”；
- GitLab Runner 使用
alpine:latest镜像时，go mod vendor生成的vendor/里部分文件权限为0000，导致go build报permission denied；解决方案是加find vendor -type f -exec chmod 644 {} \; - 如果项目已设
GO111MODULE=on且go.sum提交入库，CI 中完全可跳过vendor，直接go build——现代 Go 版本对 proxy 缓存足够健壮 - 只有当依赖中存在未公开的私有 repo（如 GitHub 私仓），且无法配
git config --global url."https://token:x-oauth-basic@github.com/".insteadOf "https://github.com/"时，才值得引入vendor
Go 的构建和测试链条看着简单，但 CI 环境里每个环节都藏着隐性假设：shell 类型、module 模式开关、CGO 状态、token 作用域、甚至文件系统大小写敏感性。跑通一次不等于稳，得盯着每条日志里的 exit code 和 warning line。
