常见失败类型全景：构建失败、测试失败、部署失败，如何快速分类定位

构建失败：最常见也最好定位

我刚开始带CI的时候，十次失败里至少有六次是构建阶段出的问题。说白了，构建失败就是你代码还没进测试环境就挂了。原因很直白——依赖拿不到、语法写错了、或者环境没搭对。

构建失败的日志特征非常明显——日志开头就会显示 Build stage 或 Stage: build。你只要看到这些关键词，就不用往下翻到测试或部署部分了。直接盯紧依赖解析和编译输出。

测试失败：多数人先怀疑自己代码写错了

构建过了，测试阶段红了。这时候很多人第一反应是“我改的代码有bug”，但其实不一定是。测试失败又分三种情况，你得先看清楚报的是哪类测试。

• 单元测试失败： 通常是单个函数或模块逻辑问题。范围小，好定位。
• 集成测试失败： 模块间交互出问题了，比如 API 返回格式变了、数据库连接超时。我自己经常遇到这种——明明单元测试都过了，一到集成就挂。后来我发现是测试环境里 mock 的数据和真实数据字段对不上。
• 代码质检失败： lint 规则、代码覆盖率不达标。这种最冤，但也好修。

嗯，这里要注意一个细节：很多CI系统会把不同测试阶段的输出混在一起。我建议你在 jest 或 pytest 的运行命令上加 --verbose 参数，这样每个测试用例的结果单独一行，一眼就能看出是哪个文件、哪条用例挂的。

部署失败：环境差异永远是元凶

测试全绿，结果部署红了？别慌。部署失败多半不是你代码的问题，而是环境差异。我遇到过最离谱的一次：本地 Docker 镜像能跑，一推到 staging 服务器就报 exec format error。折腾半天才发现是 CI 服务器是 arm64 架构，而我的镜像编译参数没指定平台。

echo "=== 环境预检 ===
OS: $(uname -m)
Docker info: $(docker info --format '{{.OSType}}/{{.Architecture}}')
Kubeconfig: $(kubectl config current-context)
Env vars: $(env | grep -E 'MY_APP_|DB_|API_')"

三句话总结快速分类逻辑

1. 看 Stage 名称：build → 构建, test → 测试, deploy → 部署
2. 看 第一个报错行：依赖、编译、语法 → 构建；断言、mock、覆盖率 → 测试；push、k8s、config → 部署
3. 如果还在纠结，就用 排除法：先确认构建是否通过（看 exit code），再确认测试是否全部 green，最后看部署日志。