最常见原因是 Runner 未启用或 job 的 tags 不匹配；需在 GitLab UI 启用 Runner，并确保 .gitlab-ci.yml 中 tags 与注册时完全一致（区分大小写、空格敏感）。

为什么 gitlab-runner register 后不执行任务？

最常见原因是 Runner 没启用或没匹配到 job 的 tags。GitLab 不会自动调度未标记、未激活、或系统级权限不足的 Runner。

• 注册后必须手动在 GitLab UI 的 Admin Area → Runners 页面点击启用（绿色开关）
• .gitlab-ci.yml 中的 tags 必须与注册时填的 tags 完全一致（区分大小写，空格敏感）
• 如果用 docker executor，确认宿主机已安装并运行 dockerd，且 gitlab-runner 用户在 docker 组里：sudo usermod -aG docker gitlab-runner
• 检查日志：sudo gitlab-runner --debug run 或查 systemd 日志：sudo journalctl -u gitlab-runner -f

Go 项目 CI 中 go mod download 失败或超慢？

私有 Runner 默认不继承宿主机 GOPROXY 设置，且国内直连 proxy.golang.org 常被阻断。

• 在 before_script 中显式设置：export GOPROXY=https://goproxy.cn,direct
• 更稳妥的做法是写进 Runner 的环境变量：编辑 /etc/gitlab-runner/config.toml，在 [[runners]] 下加：

  [runners.environment]
    GOPROXY = "https://goproxy.cn,direct"

• 避免在 go build 前反复下载依赖，可加 cache 配置缓存 go/pkg/mod 目录（注意：需用 docker 或 shell executor，ssh 不支持路径级 cache）

用 shell executor 跑 Go 测试为何提示 command not found: go？

shell executor 默认以非登录 shell 启动，不会加载 ~/.bashrc 或 /etc/profile，导致 PATH 缺失 Go 安装路径。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 确认 Go 已全局安装（如 /usr/local/go/bin/go），而非仅当前用户解压使用
• 在 config.toml 的 [[runners]] 段落中显式设置 environment：

  [runners]
    environment = ["PATH=/usr/local/go/bin:/usr/bin:/bin"]

• 或者改用 docker executor + 官方 golang:1.22-alpine 镜像，彻底规避环境差异问题

gitlab-runner 服务启动失败，日志报 Failed to load config.toml

不是文件不存在，而是格式错误——TOML 对缩进、引号、布尔值写法极其敏感，尤其从 YAML 复制配置时容易出错。

立即学习“go语言免费学习笔记（深入）”；

• 检查 config.toml 是否含制表符（TOML 只认空格）；用 cat -A config.toml 查看隐藏字符
• 所有字符串值必须用双引号包裹，比如 url = "https://gitlab.example.com/"，单引号或无引号会解析失败
• 布尔值必须小写：executor = "shell" ✔️，privileged = true ✔️，但 privileged = TRUE ❌
• 修改后务必用 sudo gitlab-runner verify 校验配置有效性，再 sudo systemctl restart gitlab-runner

Go 的构建环境本身不复杂，但 Runner 的配置层和 Shell 环境加载机制叠加之后，出问题时往往卡在某个不起眼的路径或引号上。别急着重装，先盯住 config.toml 格式和 journalctl 里的第一行报错。