Jenkins Pipeline异常处理核心是控制报错后行为，含catchError（设构建状态）、try-catch-finally（精细流控与清理）、post（按结果反馈），并支持PipelineUnit测试验证。
Jenkins Pipeline 处理异常捕获与反馈，核心是让失败不中断流程、让问题可定位、让结果可响应。关键不在“避免报错”，而在“控制报错后的行为”——包括是否继续执行、如何标记状态、怎样清理资源、向谁通知。
catchError：最简方式控制构建结果
适用于希望某段命令失败后仍让流水线跑完，并自定义最终构建状态的场景。它不拦截异常本身，而是接管异常发生后的构建结果设置。
- 基础用法：包裹可能失败的步骤，指定 buildResult（如 SUCCESS、UNSTABLE、FAILURE）
-
典型写法：
catchError(buildResult: 'UNSTABLE') { sh 'npm test' }—— 即使测试失败，整个构建仍标记为 UNSTABLE 而非 FAILURE，后续 stage 可继续运行 - 注意点：catchError 不会吞掉异常日志，错误输出仍可见；但它不提供 err 对象，无法做细粒度判断（比如区分网络超时还是语法错误）
try-catch-finally：精细控制执行流与上下文
当需要根据异常类型做不同处理、修改 currentBuild.result、记录详细错误信息、或确保清理动作必执行时，必须用 try-catch-finally。
-
try 块：放主逻辑，如
sh 'mvn deploy' -
catch 块：可捕获具体异常类型（如
catch (hudson.AbortException e)），也可用通用catch (Exception e)；常用于设置currentBuild.result = 'FAILURE'或发送告警 -
finally 块：无论成败都执行，适合清理资源（
sh 'docker rm -f app-test'）、归档临时日志、重置环境等
post 指令：统一收口构建后反馈动作
post 不是异常捕获机制，而是构建结束后按结果分类执行反馈逻辑的“收尾中枢”。它和前面两种异常处理配合使用，形成完整闭环。
- always：必执行，适合通用清理、日志归档、指标上报
- success：仅成功时触发，例如部署到预发环境、触发自动化测试、发企业微信成功通知
- failure / unstable / aborted：按实际构建状态分流，比如 failure 时自动创建 Jira 工单、上传 error.log 到对象存储、邮件通知负责人
PipelineUnit 测试中的异常验证
写好异常逻辑后，必须可测试。JenkinsPipelineUnit 支持对 catchError 和 try-catch 行为进行断言。
- 用
catchError(buildResult: 'UNSTABLE')包裹的脚本，可通过helper.getBuildResult()断言最终结果 - try-catch 中修改了
currentBuild.result，可在测试中调用runScript后检查binding.getVariable('currentBuild').result - 并行块（parallel）内出错时，框架会聚合所有异常抛出 RuntimeException，测试中可 catch 并验证异常消息是否含预期关键词
