一、先明确：fallbackFactory是谁的？
fallbackFactory是Feign 原生 API，不依赖任何熔断框架（Sentinel / Hystrix）。
- 它定义在
@FeignClient注解里，是 Feign 自己提供的降级扩展点。 - 作用：当 Feign 调用失败时，返回一个兜底实现，避免直接抛异常。
- 原生逻辑：只要调用抛异常，就触发 fallbackFactory（不管是网络、超时、还是业务异常）。
二、feign.sentinel.enabled=true到底做了什么？
这行配置是Sentinel 接管 Feign 调用的总开关。
开启后，底层发生三件关键事：
1.替换 Feign 代理
- 默认 Feign 用
FeignInvocationHandler处理调用。 - 开启后，Spring 加载
SentinelFeignAutoConfiguration，用SentinelFeign.Builder替换默认构建器，生成SentinelInvocationHandler。
2.把 Feign 调用变成 Sentinel 资源
每次 Feign 调用都会被 Sentinel 统计（QPS、响应时间、异常比例）。
3.由 Sentinel 决定是否触发降级
- 降级不再由 Feign 原生异常直接触发，而是由Sentinel 规则（限流、熔断）触发。
- 只有当 Sentinel 判定需要熔断 / 限流时，才会调用定义的
fallbackFactory。
三、总结
fallbackFactory = ...：定义降级逻辑（Feign 原生接口）。feign.sentinel.enabled=true：决定谁来触发降级（Sentinel 接管）。
四、两种模式对比
| 模式 | 触发降级的条件 | 熔断能力 | 限流能力 | 异常统计 |
| Feign 原生（未开 Sentinel） | 任何调用异常（超时、网络、业务） | 无熔断状态机 | 无限流 | 无指标统计 |
| Feign + Sentinel（开启后） | Sentinel 规则触发（熔断 / 限流） | 完整熔断（状态机） | 限流 / 热点 / 系统保护 | 实时监控 / 动态规则 |
五、回到代码
@FeignClient( contextId = "remoteUserService", value = ServiceNameConstants.SYSTEM_SERVICE, fallbackFactory = RemoteUserFallbackFactory.class )- 这行代码本身是 Feign 原生写法，定义了降级逻辑。
- 只有在
application.yml中配置feign.sentinel.enabled: true时， 这个fallbackFactory才会由 Sentinel 的熔断 / 限流规则触发，而不是 Feign 原生异常直接触发。
六、常见误区澄清
- 误区：
fallbackFactory是 Sentinel 独有的。 - 正解：不是。它是 Feign 原生，Sentinel 只是复用了这个接口。
- 误区：加了
fallbackFactory就等于用了 Sentinel。 - 正解：不等于。必须同时开启
feign.sentinel.enabled=true才是 Sentinel 整合。 - 误区：Sentinel 降级只处理 Sentinel 异常。
- 正解：开启后，
fallbackFactory会捕获所有异常（Sentinel 阻断、网络、业务），但熔断决策由 Sentinel 规则控制。
七、最终结论
fallbackFactory是 Feign 的接口，feign.sentinel.enabled决定这个回退由谁来驱动。开启后，Sentinel 熔断时就会调用定义的RemoteUserFallbackFactory。
