自动化流水线异常处理需分级响应：致命异常直接中止，可恢复异常重试，业务异常按作业粒度控制；须结构化输出错误、清理资源、标记状态，并提供人工介入与降级路径。
在自动化流水线中，异常捕获与执行中止不是“出了错就停”，而是要有明确的判断边界、分级响应策略和可追溯的终止动作。关键在于区分哪些异常必须中断流程，哪些可以降级或重试，同时确保中止后状态清晰、日志完整、资源可控。
明确异常分类与中止阈值
不能把所有报错都当成中止信号。需预先定义三类异常行为：
- 致命异常：如认证失败、核心服务不可达、配置文件缺失——直接中止整条流水线，不进入后续阶段
- 可恢复异常：如网络超时、临时限流、第三方接口503——允许配置重试次数（建议≤3次）和退避策略（如指数退避）
-
业务异常：如数据校验不通过、预期返回为空——视场景决定是否中止当前作业（job），而非整个流水线；可用
exit 1退出当前步骤，但让后续非依赖步骤继续运行
用结构化方式捕获并传递异常上下文
避免只靠echo "error"或裸exit。每个关键步骤应输出结构化错误信息，便于日志聚合与告警识别：
- 统一使用JSON格式输出错误元数据，例如：
{"stage":"build","step":"docker-build","code":"IMAGE_BUILD_FAILED","timestamp":"2024-06-12T10:30:22Z","message":"failed to pull base image"} - 将错误写入标准错误流（stderr），并确保CI平台能捕获stderr内容（如GitLab CI默认支持，Jenkins需配置
tee或插件） - 在中止前记录当前环境快照：当前分支、提交哈希、变量值（脱敏后）、执行节点标识
中止时清理资源并标记状态
中止不是简单退出，要防止残留影响下次执行：
- 使用
trap机制注册清理函数（Shell）或finally块（Python/Node.js），释放临时目录、解锁共享资源、关闭数据库连接 - 向外部系统（如配置中心、监控平台）上报中止事件，包含唯一流水线ID、阶段名、错误码，用于自动归因分析
- 在制品仓库或对象存储中标记本次构建为
aborted，避免被下游误取；若已上传部分产物，添加.broken后缀或移入隔离桶
提供人工介入入口与降级路径
完全自动中止可能过度保守。对某些关键但非阻断性异常，应留出干预窗口：
- 配置“人工确认点”：当检测到特定警告（如测试覆盖率下降5%以上），暂停流水线，通知负责人，超时未响应则按预设策略继续或中止
- 支持运行时覆盖中止策略：通过环境变量（如
SKIP_ON_WARNING=true）临时跳过某类检查，适用于紧急发布场景 - 为高频异常设计旁路逻辑：例如镜像构建失败时，自动回退到上一版稳定镜像拉取并打标，保证部署链路不断
异常处理不是越严格越好，而是让中止动作本身成为可读、可配、可审计的一环。真正健壮的流水线，能在出错时说清“为什么停”、“停在哪”、“怎么修”。
