Activiti中异常不自带节点信息，需通过DelegateExecution.getCurrentActivityId()或executionId查询获取；推荐在JavaDelegate中记录节点ID并封装异常，避免依赖getCause()。
在 Activiti 工作流中，当流程执行出错（比如 JavaDelegate 抛异常、表达式解析失败、服务任务执行异常等），原始异常通常被层层包装（如 BpmnError、ActivitiException、RuntimeException 等）。此时直接调用 getCause() 并不能直接定位到“哪个节点”出了问题——getCause() 只返回异常链中的下一层原因，不包含流程节点信息。
异常本身不携带节点信息，需结合执行上下文获取节点ID
Activiti 的异常对象（如 ActivitiException）默认不含当前执行的节点 ID 或活动 ID。要定位出问题的节点，关键不是靠 getCause()，而是：
- 从异常触发时的
DelegateExecution或ExecutionEntity中提取getCurrentActivityId()或getActivityId() - 若异常发生在监听器或委托类中，该对象通常作为参数传入，可直接使用
- 若异常来自异步任务或未捕获位置（如全局异常处理器），需通过
executionId查询运行时执行实例：runtimeService.createExecutionQuery().executionId(executionId).singleResult()
再调用getCurrentActivityId()
在 JavaDelegate 中安全捕获并关联节点
推荐在委托类中主动记录节点上下文，而不是依赖异常链：
- 在
execute(DelegateExecution execution)方法开头打印或记录：log.info("Executing node: {}", execution.getCurrentActivityId()); - 用 try-catch 包裹业务逻辑，捕获后手动构造带节点信息的异常：
throw new RuntimeException("Failed at node [" + execution.getCurrentActivityId() + "]: " + e.getMessage(), e); - 这样即使后续被包装，日志或根异常消息里已明确包含节点 ID
从已发生的异常反查节点（无原始 execution 时）
如果只能拿到一个抛出的异常对象（例如全局 @ControllerAdvice 拦截到的），且没有保存 execution 引用，可尝试以下方式补救：
立即学习“Java免费学习笔记（深入）”；
- 检查异常是否为
ActivitiOptimisticLockingException或ActivitiIllegalArgumentException等，它们有时会包含 executionId 字符串（如 message 中含executionId=123），可正则提取后查库 - 查看异常堆栈，搜索
org.activiti.engine.impl.相关行，常能看到executeActivity或performOperation调用，其上层帧可能隐含 activityId（不保证，仅辅助） - 启用 Activiti 的 DEBUG 日志（如
org.activiti.engine.impl.interceptor），日志中会在执行每个节点前输出 activityId，可与异常时间戳对齐定位
避免误用 getCause() 的典型误区
getCause() 在这里的作用有限，常见错误包括：
- 反复调用
e.getCause()直到为 null，期望某一层是 “NodeException” —— Activiti 不定义此类异常 - 认为
ActivitiException的 cause 里有节点信息 —— 实际 cause 通常是底层技术异常（如NullPointerException、SQLException） - 忽略执行上下文生命周期：DelegateExecution 在方法退出后即不可用，不能存为字段再取
