Go项目CI需确保模块路径、工作目录和go版本一致，避免静默失败；多module时go test -v ./仅测当前module；windows交叉编译须加.exe后缀；github_token需显式设contents: write权限；标签触发用if: startswith(github.ref, 'refs/tags/')。
Go语言持续集成方案不是“学完再搭”，而是边写代码边跑起来——只要go.mod能解析、go test能通过，CI 就已经可以动了。
GitHub Actions 中 go build 和 go test 怎么写才不踩坑
很多人卡在第一步：CI 跑到 go build 就报错找不到包，或 go test 因环境差异失败。根本原因不是语法错，而是工作目录和模块路径没对齐。
- 必须在项目根目录（含
go.mod的那层）执行所有go命令；GitHub Actions 默认工作目录是仓库根，但如果你用了子目录结构（比如/src），就得用working-directory显式指定 -
go test ./...会递归跑所有子包，但若某个 internal 包里有依赖本地文件（如testdata/），而 CI 没复制该目录，就会 panic——建议在测试前加cp -r testdata ./或改用os.DirFS安全读取 - 别在 CI 里用
go get动态拉依赖；go mod download或直接靠go build自动触发模块下载更稳，且能复用 GitHub Actions 的actions/cache@v4缓存~/go/pkg/mod
golangci-lint 在 CI 里为什么总过不了本地能过的代码
本地开发时可能忽略 lint 报错，或者用了不同版本的 golangci-lint，CI 一跑就失败。这不是风格问题，是配置漂移。
- CI 必须锁定
golangci-lint版本，例如用rev: v1.54.2（不要只写v1），否则某天自动升级后规则变严，批量报错 - 检查
.golangci.yml是否包含run: skip-dirs或exclude-rules，这些在本地 IDE 插件里可能被忽略，但 CI 会严格执行 - 如果项目用了
//nolint注释绕过检查，确保它写在正确行——//nolint:govet必须紧贴出问题的那行代码上方，不能隔空行
交叉编译产物怎么传给后续部署步骤
CI 构建出的二进制文件（比如 linux/amd64 和 darwin/arm64）默认只存在 runner 临时磁盘，下个 job 拿不到。得主动“搬走”。
立即学习“go语言免费学习笔记（深入）”；
- 用
actions/upload-artifact@v4上传构建产物，name建议带架构标识，如myapp-linux-amd64，避免多平台同名覆盖 - 部署 job 里用
actions/download-artifact@v4下载，注意path参数要设成非默认值（比如./dist），否则解压后文件散落在工作目录，容易误删 - 如果部署目标是 Kubernetes，别把二进制塞进镜像再推——直接用
docker build --platform linux/amd64+ 多阶段构建，在 Dockerfile 里COPY对应架构的 artifact 更可靠
真正难的不是写对某一行 YAML，而是让 go test、golangci-lint、go build -ldflags 这三者在本地和 CI 中输出一致——所有差异点都得显式声明，不能靠“应该一样”。
