go项目ci中go test必须加-v、-p=1、-timeout=60s、-race参数，并禁用log.fatal/os.exit(1)；覆盖率需用-covermode=count生成coverage.out，再通过grep校验是否≥80%。
Go 项目本地能跑通 go test，不等于 CI 里能稳住 —— 环境差异、并发干扰、超时静默、覆盖率失真，这些才是真实阻塞上线的点。
go test 命令在 CI 中必须加哪些参数
CI 不是本地开发，不能依赖默认行为。漏掉关键参数会导致测试“看似通过”，实则跳过错误路径或卡死不报错。
-
-v：强制输出每个测试用例名和失败详情，否则 CI 日志里只显示PASS或FAIL，无法定位具体哪一行挂了 -
-p=1：禁用并行执行，避免多个测试共用临时文件、端口或全局状态引发竞态（尤其涉及os.TempDir()或 HTTP server 启动时） -
-timeout=60s：防止某条测试因网络延迟、DB 连接未设 timeout 而无限等待，拖垮整个流水线 -
-race：必须启用，Go 的竞态检测器只在编译期插桩，CI 是唯一能低成本暴露数据竞争的地方 - 避免
log.Fatal和os.Exit(1)：它们会绕过testing.T的错误收集机制，导致测试进程直接退出，CI 显示ok实际已中断
覆盖率怎么生成才可信，又怎么卡住低覆盖提交
CI 里只跑 go test -cover 打印个百分比毫无意义。真正要的是可聚合、可校验、能拦截的覆盖率数据。
- 用
-covermode=count替代默认的atomic，它记录每行执行次数，支持多包合并且对 error path 更敏感 - 生成
coverage.out后，用go tool cover -func=coverage.out | grep "total:"提取总覆盖率行 - 在 shell 步骤中加校验逻辑：
grep -q 'total.*[8-9][0-9]\.[0-9]%' coverage.out || exit 1，低于 80% 就让 job 失败 - 别信单个包的覆盖率 —— 主逻辑可能 100%，但
internal/handler下的错误处理分支完全没测，-covermode=count+ 多包合并才能暴露这类盲区
为什么本地测试全绿，CI 却 panic 或 connect refused
95% 的原因是环境假设被打破。CI 容器是干净、隔离、无状态的，而本地开发机常年运行着 PostgreSQL、Redis、mock server。
- 数据库连接失败？不要硬连本地
localhost:5432，改用testcontainers-go或内存 SQLite（sqlite3,":memory:"）启动临时实例 - HTTP 端口被占？别写死
:8080，用net.Listen("tcp", ":0")让系统分配空闲端口，再从l.Addr().Port拿实际值 - 临时目录不可写？
os.MkdirAll前先检查权限，或统一用t.TempDir()（它自动注册 cleanup，且保证可写） - Go 版本差异触发 panic？CI 显式指定
go-version: '1.22'，和本地go version对齐，避免 1.21 的 nil map 写入在 1.22 下 panic
golangci-lint 怎么集成才不变成摆设
装上工具不等于质量提升。lint 错误必须阻断构建，且规则要贴合团队真实风险点。
- 在
.golangci.yml中禁用泛泛而谈的风格检查（如gofmt），重点启用staticcheck（空指针、死代码）、errcheck（忽略 error 返回值）、govet（结构体字段错位） - CI 步骤里加
--timeout 5m，防止 lint 在大项目里卡死；同时设issues-exit-code: 1，任意警告即失败 - 别把 lint 当成“代码洁癖”——比如
unused检查对pkg/下导出函数无效（因为外部可能引用），应只对internal/启用 - 第一次接入时用
--new-from-rev=HEAD~1只检查本次变更，避免历史债阻塞 pipeline
最常被忽略的一点：所有测试和 lint 步骤都得跑在同一个 runs-on 环境里，且缓存 GOCACHE 和 go mod download 结果。否则每次都是冷启动，8 分钟流水线里 5 分钟花在下载依赖和重编译上 —— 自动化就只剩“自动等”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
