不需要设置GOPATH，Go 1.11+默认启用模块模式，go.mod存在时GOPATH不影响构建；手动设GOPATH反而干扰模块解析，应禁用CGO、缓存pkg/mod和build-cache、用artifacts传递二进制。
Go 项目在 GitLab CI 中必须设置 GOPATH 吗？
不需要，且不推荐。Go 1.11+ 默认启用模块模式（GO111MODULE=on），项目根目录有 go.mod 时，GOPATH 不再影响构建路径。GitLab Runner 默认工作目录就是仓库检出路径，只要 go build 能读到 go.mod，就可直接运行。
常见错误是手动设置 GOPATH 指向 /builds/xxx 并把代码挪进去——这反而会干扰模块解析，导致 go: cannot find main module 或依赖拉取失败。
- 确保项目根目录存在
go.mod（用go mod init初始化） - CI 中显式启用模块：在
.gitlab-ci.yml里加export GO111MODULE=on（或设为 job 的variables） - 避免覆盖
GOPATH；如需清理缓存，删$HOME/go/pkg/mod即可，不影响构建逻辑
go test 在 CI 中跑不通过，本地却正常？
典型原因是环境差异：本地有 GOPROXY 缓存、DNS 解析正常、测试依赖的端口未被占、或用了 os.Getenv 读取了本地配置。CI 容器默认无网络代理、无自定义环境变量、资源隔离严格。
- 在
.gitlab-ci.yml中统一设置GOENV=off防止读取本地go.env - 用
go test -v -short快速跳过耗时集成测试（需代码中用if testing.Short() { t.Skip() }判断） - 网络相关测试要 mock HTTP client 或用
httptest.Server，别直连外部服务 - 检查是否误用了
time.Now()或rand导致非确定性失败；改用注入时间源或固定 seed
如何复用 Go 构建产物并跳过重复编译？
GitLab CI 默认每次 job 都是干净环境，但可通过 cache 或 artifacts 复用中间产物。关键不是缓存二进制文件本身（它体积小、生成快），而是缓存 $HOME/go/pkg/mod 和 $HOME/go/build-cache 来加速依赖下载和增量编译。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 在
.gitlab-ci.yml中配置 cache：
cache:
key: "$CI_PROJECT_NAME"
paths:
- "$HOME/go/pkg/mod"
- "$HOME/go/build-cache"go build 加 -buildmode=exe -trimpath -ldflags="-s -w" 减小体积、去除调试信息artifacts 声明路径（如 bin/myapp），不要依赖 cache 传递可执行文件交叉编译 Linux 二进制却在 macOS 上触发 CGO？
CGO_ENABLED=1 是 macOS 默认值，而交叉编译 Linux 二进制时若依赖 cgo（比如用了 net 包的某些 DNS 解析逻辑），会因缺少 x86_64-linux-gnu-gcc 报错 exec: "gcc": executable file not found。
- 绝大多数纯 Go 项目应禁用 cgo：
CGO_ENABLED=0 go build -o bin/app . - 仅当明确需要系统库（如 SQLite、OpenSSL）时才开启，并在 CI 镜像中预装对应交叉编译工具链（如
gcc-x86-64-linux-gnu） - 检查是否无意引入 cgo：运行
go list -json -deps . | jq 'select(.CgoFiles != null)'可定位含 cgo 的包
真正麻烦的不是编译失败，而是某些依赖（比如 golang.org/x/sys/unix）在不同平台行为不一致，测试通过但线上 panic —— 这类问题只能靠目标平台 CI job 覆盖验证。
