Jenkins流水线可通过catchError实现在上游非核心依赖（如配置中心、镜像仓库）临时不可用时的有条件容错，保持主构建成功但标记阶段为UNSTABLE，并支持fallback逻辑与失败汇总。
当上游依赖（如配置中心、镜像仓库、内部 API）临时不可用，但又不直接影响主构建逻辑时，Jenkins 流水线可通过 catchError 实现有条件容错，避免因非关键环节失败中断整个流程。
明确“非核心依赖”的判定标准
先确认哪些环节属于可降级或可跳过的非核心依赖：
- 拉取远程共享脚本（如
curl -s https://config.example.com/pipeline-lib.sh） - 查询外部服务健康状态（如
curl -f http://registry/internal/health） - 推送构建元数据到监控平台（如上报指标到 Prometheus Pushgateway）
- 触发非阻塞式通知（如 Slack 预告消息，非构建结果通知）
用 catchError 包裹单个非核心步骤
对每个独立的非核心调用使用 catchError，并设置合理的状态映射：
- 保持整体构建成功：
buildResult: 'SUCCESS' - 标记该阶段为失败以便追溯：
stageResult: 'UNSTABLE'或'FAILURE' - 配合日志说明降级行为，例如：“Registry check failed → using cached config”
示例：
stage('Fetch Config') {
steps {
script {
catchError(buildResult: 'SUCCESS', stageResult: 'UNSTABLE') {
sh 'curl -f -o config.yaml https://config.internal/v1/build-config'
}
// 后续逻辑仍可执行，例如检查文件是否存在再决定是否加载
if (fileExists('config.yaml')) {
echo 'Using fetched config'
} else {
echo 'Falling back to default config'
sh 'cp defaults/config.yaml config.yaml'
}
}
}
}
组合 returnStatus 与 catchError 提升可控性
对需要细粒度判断的命令（如 curl 返回 404 或超时），优先用 returnStatus: true 获取退出码，仅在真正需忽略时才进 catchError：
- 404 可能表示配置暂未发布，应继续；5xx 表示服务异常，可记录但不中断
- 避免将
|| true这类模糊写法混入脚本，所有容错逻辑应在 Pipeline 层显式表达 - 示例中可先用
sh(returnStatus: true)捕获状态，再根据 code 值决定是否error或静默跳过
统一处理多个非核心依赖的失败汇总
若多个非核心步骤并行执行（如同时检查 registry、config、metrics），可用 parallel + catchError 分别包裹，并在最后汇总状态：
- 用
currentBuild.result = 'UNSTABLE'在任意一个失败后升级整体状态（但不中断） - 将各步骤错误信息收集到变量，在 post 阶段统一输出报告
- 确保最终部署或发布步骤前有显式校验（如
if (deployEnabled) { ... }），防止误发降级产物
