执行器回调超时会导致调度中心误判任务失败：调度中心默认3秒内未收到执行器/callback接口响应，即标记为失败并重试，即使任务实际已成功执行；常见原因包括执行器线程池满、回调通道被禁用、防火墙/Nginx拦截、JVM长时间GC等，需同步调整调度中心xxl.job.admin.callback.timeout与执行器HTTP客户端connect/read timeout配置。
执行器回调超时会导致调度中心误判任务失败
XXL-JOB 调度中心在发起一次调度后，会等待执行器通过 /run 接口返回结果。若执行器未在约定时间内（默认 3 秒）完成回调（即未调用 /callback），调度中心会认为该次执行“失败”或“丢失”，并在下一轮调度周期中再次触发——哪怕任务其实在执行器端已成功运行并仍在处理中。这种“假失败 → 真重试”是重复触发的典型诱因。
确认是否为回调超时：看调度日志里的 trigger_code 和 handle_code
进入「调度日志」页，筛选目标任务，重点检查最近几次记录的两个字段：
-
trigger_code=200表示调度成功发出，但不等于执行成功 -
handle_code=0或为空、或长时间未更新，说明执行器未完成回调 - 若连续多条记录中
trigger_code=200但handle_code始终为 0 或缺失，且handle_msg含 “timeout”、“no response”、“callback not received” 等字样，基本可锁定为回调超时
常见回调超时原因与对应检查点
不是所有“没回”都是网络问题，得按链路分段验证：
- 执行器线程池已满：
xxl.job.executor.corepoolsize过小 + 任务阻塞（如 DB 连接未释放、HTTP 无超时），导致无空闲线程处理/callback请求；查执行器日志是否有RejectedExecutionException - 执行器主动关闭了回调通道：某些定制化改造中误删或禁用了
XxlJobCallbackBean的注册逻辑，或 Spring 上下文未加载该 Bean - 防火墙/Nginx 拦截了回调请求：调度中心访问执行器的
/callback路径被丢弃，尤其注意 Nginx 默认proxy_read_timeout是 60 秒，但 XXL-JOB 回调超时阈值远小于此，需确保反向代理未提前中断长连接 - 执行器 JVM Full GC 长时间 STW：GC 日志中出现 >3s 的 pause，会直接卡住整个回调处理线程
调整 timeout 配置需同步修改两端
单纯加长调度中心的超时时间（xxl.job.admin.trigger.pool.fast.max-queue-size 相关参数无效）没用。真正起作用的是这两个配置项，且必须两端一致：
- 调度中心侧：
xxl.job.admin.callback.timeout（单位毫秒，默认 3000） - 执行器侧：
xxl.job.executor.logretentiondays不影响回调，真正控制回调等待的是执行器启动时初始化的callbackThreadPool与底层 HTTP 客户端超时——Golang 执行器需设http.Client.Timeout，Java 执行器需确保RestTemplate或OkHttpClient的 connect/read timeout ≥ 调度中心的callback.timeout - 切忌只改一端：比如把调度中心设为 10s，执行器 HTTP 客户端仍用默认 3s，那执行器发出去的回调请求自己就先超时了
回调超时问题最隐蔽的点在于：它不报错，也不中断任务本身，只是让调度中心“失联”。很多团队花大量时间排查任务逻辑或路由策略，却忽略了调度中心和执行器之间这条细如发丝的回调通路是否真的畅通。
