GitLab CI运行Go流水线失败主因是环境未初始化：须在.gitlab-ci.yml中显式设GOPATH="$CI_PROJECT_DIR/.go"、GO111MODULE=on，并将GOMODCACHE和GOCACHE指向项目内路径，确保go.mod位于根目录且缓存键稳定。
GitLab CI 跑不起来 Go 流水线？大概率不是语法问题，而是环境变量、缓存路径或 go build 输出位置没对齐。
Go 编译阶段总报 cannot find package 或 no required module provides package
根本原因是 GOPATH 和 Go Modules 环境没初始化到位。GitLab Runner 默认不带 GOPATH 隔离，go mod 会误读全局缓存或找不到 go.mod 上下文。
- 必须在
.gitlab-ci.yml开头显式设置：GOPATH: "$CI_PROJECT_DIR/.go"，并让GO111MODULE=on -
GOMODCACHE和GOCACHE也得指向项目内目录（如$CI_PROJECT_DIR/.modcache），否则缓存无法跨 job 复用 - 不要依赖 runner 宿主机的
~/.go或系统级 GOPATH —— CI 环境是干净且无状态的 - 确认
go.mod文件在仓库根目录；如果项目在子目录，需在script中先cd ./cmd/myapp再执行go build
go test -coverprofile 生成了 cov.out，但 GitLab CI 不显示覆盖率报告
GitLab 本身不解析 cov.out，需要手动提取数值并注入到 job 日志中，才能被 GitLab 的覆盖率正则识别（默认匹配 coverage: [0-9.]+%）。
- 必须用
-covermode=atomic（并发安全），count或set模式在并行测试下结果不可靠 - 加一行
go tool cover -func=cov.out | tail -n 1 | awk '{print "coverage:", $NF}'，确保末行输出形如coverage: 72.5% - 若要卡阈值（比如 PR 要求 ≥70%），用 shell 提取数值：
COV=$(go tool cover -func=cov.out | tail -n 1 | awk '{print $NF}' | sed 's/%//'); [ "$COV" -lt "70" ] && exit 1 - 别指望
go tool cover -html自动生成页面再上传 —— GitLab UI 不渲染它，纯属白忙
Docker 构建阶段镜像体积过大，或 docker build 报 cannot stat '/workspace': no such file or directory
这是典型的多阶段构建上下文错位：GitLab CI 的 docker:dind service 默认挂载的是 /builds，不是 /workspace；且 Go 编译产物若没明确输出到工作区，COPY 就会失败。
Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。 触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。 当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使
立即学习“go语言免费学习笔记（深入）”；
- 在 build 阶段用
go build -o ./bin/app -ldflags="-s -w" .，强制输出到./bin/目录（别用go install） - Dockerfile 第一阶段 FROM golang:1.22，第二阶段 FROM alpine:3.19，COPY --from=0 /builds/
$CI_PROJECT_PATH/bin/app /app - 确认
.gitlab-ci.yml中启用services: - docker:dind，并设置DOCKER_HOST: tcp://docker:2376 - 避免在 Dockerfile 中写
COPY . .—— 整个 repo 传进容器太慢，只 COPY 编译好的二进制和必要配置
部署到 Kubernetes 总失败，kubectl 报 error: You must be logged in to the server
不是 token 过期，而是 CI job 没加载 kubeconfig，或者 context 名字和集群实际不匹配。
- 把 kubeconfig 文件 base64 后存为 GitLab 变量（如
KUBECONFIG_BASE64），在 deploy job 中解码：echo $KUBECONFIG_BASE64 | base64 -d > $HOME/.kube/config - 检查 config 里
current-context是否对应目标集群名；不一致就用kubectl config use-context my-prod-cluster - 别用
kubectl apply -f k8s/直接推全量 —— 优先用kubectl set image deployment/myapp myapp=$CI_REGISTRY_IMAGE:$CI_COMMIT_TAG，更轻量、更可控 - 如果用 Helm，确保
HELM_KUBEAPISERVER和HELM_KUBECONFIG环境变量已设，且 Helm 版本与集群 API 兼容（v3.12+ 推荐）
最常被忽略的一点：GitLab CI 的 cache 键必须稳定，建议用 cache:key: "$CI_PROJECT_NAME-go-modules" 而非 cache:key: "$CI_COMMIT_REF_SLUG" —— 否则不同分支的缓存互不共享，每次都要重下 modules，白白拖慢流水线。
