该问题本质是重试逻辑与调用链路耦合不当引发的“堆栈膨胀”，表现为日志嵌套、APM链路纵向延伸、堆栈末尾框架类循环出现，根源在于Feign/Ribbon/自定义代码/Hystrix fallback等多层重试叠加，修复需统一收口、禁用冗余重试、避免fallback递归调用。
这个问题本质是重试逻辑与调用链路耦合不当引发的“堆栈膨胀”，不是真正的无限递归，但表现类似：日志里看到层层嵌套的 feign.Client → RetryableFeignClient → HystrixCommand → 再进一层 Feign……最终触发 StackOverflowError 或被 JVM 主动截断，trace ID 深度异常增长，甚至 APM 中显示单次请求调用深度超百层。
识别是否为重试导致的堆栈包裹
关键看三类线索：
-
日志中出现重复、嵌套的客户端调用标识：比如同一 trace ID 下，连续出现
callOrderService→callOrderService (retry #1)→callOrderService (retry #2)，且每层都带完整调用栈（非简单日志打点） - APM 链路中方法节点呈“阶梯式纵向延伸”：不是并行分支，而是单一线程内持续向下压栈，每个重试动作都新增一个完整子 span，而非复用原 span 的重试标记
-
错误堆栈末尾反复出现相同框架类：如
feign.SynchronousMethodHandler.invoke→feign.RetryableFeignClient.execute→feign.ReflectiveFeign$FeignInvocationHandler.invoke循环出现 50+ 次
检查重试配置是否跨层叠加
微服务中重试常在多个层级被无意启用，形成“重试嵌套”：
-
Feign 层开启 retryer：如配置了
feign.client.config.default.retryer，且未限制最大重试次数或退避策略 -
Ribbon 层也启用重试：
ribbon.MaxAutoRetries和MaxAutoRetriesNextServer同时生效，会在客户端负载均衡阶段再兜一次底 - 上层再包一层自定义重试逻辑：比如 Service 方法里手动 catch 异常 + while 循环调用 Feign 接口，而 Feign 本身已重试过
- 熔断器（如 Hystrix/Sentinel）配置了 fallback 且 fallback 内又调用同名接口：造成“失败→fallback→再调用→再失败→再 fallback”的隐式循环
定位具体触发点的方法
不依赖猜测，用可验证手段缩小范围：
- 临时关闭所有重试配置：注释掉 Feign retryer、Ribbon 重试、自定义重试代码，只保留最基础调用。若堆栈深度回归正常（如稳定在 3–5 层），即可确认是重试滥用所致
-
在 Feign Client 执行入口加线程栈深度打印：在
SynchronousMethodHandler.invoke开头插入Thread.currentThread().getStackTrace().length，观察数值是否随每次重试线性增长 -
检查 trace 上下文传播是否异常：若使用 SkyWalking 或 Pinpoint，确认
trace_id和span_id在重试后是否仍沿用原始值；若每次重试都生成新 span 且 parent_id 指向自身，则说明上下文未正确复用，加剧栈膨胀
修复与预防建议
核心原则：重试必须有边界、有归属、不重叠。
-
统一收口重试逻辑：只在 Feign 层启用 retryer，并设置合理参数，例如：
maxAttempts: 3，period: 100，maxPeriod: 1000，禁用 Ribbon 级重试（ribbon.OkToRetryOnAllOperations=false） - 避免 fallback 调用原接口：fallback 方法应返回默认值、缓存数据或降级结果，严禁再次发起远程调用
-
对重试行为做可观测增强：在 retryer 的
continueOrPropagate方法中埋点，记录重试次数、原因、耗时，接入监控看板，一旦某接口重试率突增，立即告警 - 在网关层设重试熔断开关：对 P99 超过 2s 或重试率 >5% 的下游服务，自动关闭其重试能力，防止雪球效应
