RequestInterceptor 仅在请求前预设不可变的 RequestTemplate，无法通过异常链重构它；异常处理应交由 ErrorDecoder 和 Retryer 协作完成。
在 OpenFeign 中，RequestInterceptor 的职责是修改请求前的 RequestTemplate，它本身不处理异常，也不参与异常链传播。所谓“利用异常链重构 RequestTemplate”存在概念混淆——RequestTemplate 是构建阶段的不可变模板对象，不能在拦截器中被“重构”或“重写”，更无法通过异常链去影响它。异常链（如 throw new RuntimeException("...", cause)）发生在执行阶段（FeignClient 调用后），此时请求早已发出或失败，RequestTemplate 已固化为 HTTP 请求，不可再变更。
拦截器中只能预设模板，不能响应异常
RequestInterceptor 的 apply(RequestTemplate template) 方法在请求发起前调用，此时还没有网络通信，也没有任何异常发生。它只能读取上下文（如 ThreadLocal 中的用户信息、TraceID）、添加 Header、修改 URL 或 Query 参数等静态操作。
- 模板一旦 apply 完成，Feign 就用它生成真实 HTTP 请求，后续异常（如 ConnectException、TimeoutException、4xx/5xx 响应）都属于执行期问题
- 你无法在拦截器里“捕获异常”来反向修改已生成的模板——那既违反时序，也违背 Feign 设计模型
- 试图用 try-catch 包裹
template.method(...)并抛出新异常来“触发重构”，只会中断请求，不会让 Feign 回退并重新 apply 拦截器
真正需要“动态调整请求”的场景，应换用其他机制
若业务要求根据失败原因（比如 token 过期 401）自动刷新 token 并重试请求，这不是拦截器能解决的，而需组合以下能力：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
自定义 ErrorDecoder：捕获响应异常（如 401），解析响应体，提取错误码，返回自定义异常（如
AuthExpiredException） -
Retryer + 自定义重试逻辑：配合
ErrorDecoder，在重试前通过Request.Options或ThreadLocal注入新凭证 -
装饰 FeignClient（如用 @Bean + Builder）：在重试前手动重建
RequestTemplate，例如调用鉴权服务获取新 token，再构造新请求
如果坚持要在“异常路径”影响下一次请求，推荐标准做法
典型 Token 刷新流程示例（不侵入拦截器，而是解耦协作）：
立即学习“Java免费学习笔记（深入）”；
- 定义
TokenRefresher服务，提供refreshToken()方法，返回新 token 字符串 - 实现
CustomErrorDecoder，当 status == 401 时抛出TokenExpiredException - 配置
Retryer，对TokenExpiredException最多重试 1 次，并在 retry 之前调用TokenRefresher.refreshToken() - 将新 token 存入
ThreadLocal<String>或RequestContextHolder，确保下次RequestInterceptor.apply()可读取并写入 Header
小结：别在拦截器里做异常驱动的模板修改
OpenFeign 的生命周期很清晰：拦截器 → 构建 RequestTemplate → 发送请求 → 接收响应 → 解码 → 抛异常。跨阶段反向修改不符合设计原则。正确方式是把“异常感知”和“请求重建”拆开：用 ErrorDecoder 捕获语义错误，用 Retryer 控制重试时机，用外部状态（如 ThreadLocal）桥接两次请求间的上下文。这样既清晰又可测，也不会破坏 Feign 的不可变模板模型。
