GitHub Actions 的 .github/workflows/cd.yml 文件写在哪、怎么触发
工作流文件必须放在仓库根目录下的 .github/workflows/ 目录里，文件名任意但后缀得是 .yml 或 .yaml。GitHub Actions 不会自动扫描或加载其他路径的配置。
触发方式靠 on: 字段定义，常见组合有：
-
push到main分支（上线部署用） -
pull_request打开或更新 PR（做代码检查和测试） -
workflow_dispatch手动触发（适合需要参数的发布操作）
别把 on: push 和 on: pull_request 写进同一个 job 里还指望它“智能区分”，它们是独立触发事件；想复用逻辑，得拆成不同 job 或用 if: github.event_name == 'push' 做条件判断。
Go 项目在 CI 中编译失败：go: cannot find main module
这是最常遇到的报错，根本原因是 GitHub Actions 默认 checkout 后不在模块根目录执行命令，或者 go.mod 文件缺失/位置不对。
立即学习“go语言免费学习笔记（深入）”；
解决办法很简单，但容易漏掉细节：
- 确认
go.mod在仓库根目录（不是子目录），且内容包含有效module声明 - 在
steps中加一步：run: ls -la，先看当前工作目录下有没有go.mod - 如果项目结构是
cmd/myapp/go.mod，就得用working-directory: ./cmd/myapp指定路径 - 别依赖
go get安装工具再跑构建——Go 1.21+ 默认启用GOPROXY=direct时会失败，显式加上env: GOPROXY: https://proxy.golang.org,direct
goreleaser 发布二进制时卡住或生成空包
goreleaser 不是黑盒工具，它严格依赖项目结构和 tag 规范。没打 tag 就运行，它会静默跳过发布；打了 v1 这种非语义化 tag，它直接报错退出。
实操要点：
- 发布前必须
git tag v1.2.3 && git push origin v1.2.3，tag 名称必须匹配version: '{{ .Tag }}'或默认规则 -
.goreleaser.yml里builds[].main要指向含func main()的文件，比如./cmd/myapp/main.go，不能只写. - CI 中用
goreleaser release --clean，但得确保 runner 有写权限（默认GITHUB_WORKSPACE是只读挂载？不，它是可写的，但--clean会删掉 dist/，所以别让它清掉你前面 build 好的产物） - 如果生成的二进制体积异常小（几 KB），大概率是
builds[].binary配错了，导致打包了错误文件
如何让 Go 测试在 CI 里真正跑起来，而不是跳过
本地 go test 成功 ≠ CI 里成功。环境差异、依赖缺失、测试超时都会让测试“假装通过”。
关键控制点：
- 加
-v参数：go test -v ./...，不然失败时只输出FAIL，看不到具体哪个 case 崩了 - 禁用缓存：
go test -count=1 ./...，否则 CI 可能复用上一次成功的缓存结果 - 设置超时：
go test -timeout=60s ./...，避免某个死循环测试拖垮整个 workflow - 如果用了
os.Getenv读配置，记得在env:下补全，比如TEST_DB_URL: sqlite://file:test.db?mode=memory
还有个隐蔽坑：某些测试依赖本地时区或 DNS，CI runner 默认是 UTC + no /etc/resolv.conf，time.Now().Zone() 或 net.LookupIP 可能行为突变——这种没法靠改配置修，得在测试里 mock。
