hystrixcommand 不生效的根本原因是未在 hystrix 上下文中执行，如直接 new 后调用 execute() 而非 queue().get()，或未启用熔断器注解、未引入依赖、self-invocation 导致 aop 失效、超时关闭导致 fallback 不触发、误用信号量隔离（不支持超时降级）等。
为什么 HystrixCommand 不生效，降级逻辑完全没触发？
根本原因通常是命令没真正执行在 Hystrix 线程池或信号量上下文中，而是被直接同步调用。比如手动 new HystrixCommand 后直接调用 execute()，但没走 queue() + get() 流程，或忘了继承 HystrixCommand 而误用了普通类。
- 必须通过
execute()（阻塞）或queue().get()（异步）启动执行，否则熔断器不介入 - Spring Cloud Netflix 1.4+ 默认关闭 Hystrix 自动代理，需显式加
@EnableCircuitBreaker或@EnableHystrix - Spring Boot 2.x + Spring Cloud Finchley 及之后，
Hystrix已从默认依赖移除，不引入spring-cloud-starter-netflix-hystrix就根本没类 - 方法上加了
@HystrixCommand却没生效？检查是否在同一个类内调用——Spring AOP 代理失效于 self-invocation
配置 hystrix.command.default.execution.timeout.enabled 时要注意什么？
这个开关控制整个超时机制是否启用，默认为 true，但一旦设成 false，不仅跳过超时判断，连 fallback 都可能不进——因为很多降级条件（如 TIMEOUT）依赖超时异常被抛出才能被捕获。
-
execution.timeout.enabled = false时，execution.isolation.thread.timeoutInMilliseconds设置无效 - 若业务本身有内部重试（如 OkHttp 的 connect timeout），建议保持 Hystrix 超时开启，并让其值 > 底层客户端超时总和
- Feign 用户注意：
feign.hystrix.enabled=true必须打开，否则@FeignClient接口上的@HystrixCommand不会被织入
线程池隔离 vs 信号量隔离：选错会导致降级永远不触发
线程池模式（默认）适合外部 HTTP、DB 等耗时不可控调用；信号量模式只做并发数限制，不支持超时和真正的降级，但开销小。很多人在高 QPS 场景下盲目切信号量，结果发现 fallback 从不执行——因为信号量模式下，超时异常根本不会抛出，getFallback() 只响应 RuntimeException 和熔断状态。
- 信号量模式下，
execution.isolation.strategy=SEMAPHORE，此时execution.isolation.thread.timeoutInMilliseconds完全无效 - 信号量无法拦截慢请求，只能等它自己跑完或抛异常，所以“降级”实际只发生在失败或熔断时，不是超时
- 线程池模式要注意
coreSize和maxQueueSize：队列满后新请求直接走 fallback，而不是排队等待
Spring Boot 2.1+ 中 HystrixMetricsStreamServlet 404 怎么办？
因为 Actuator 路径和 Servlet 注册方式变了。老写法 @Bean public ServletWebServerFactory servletContainer() 不再自动注册 HystrixMetricsStreamServlet，必须显式暴露端点并配置路径。
立即学习“Java免费学习笔记（深入）”；
- 加配置：
management.endpoints.web.exposure.include=hystrix.stream - 确保依赖含
spring-boot-starter-actuator和hystrix-metrics-event-stream - 访问地址变为：
/actuator/hystrix.stream（不是旧版的/hystrix.stream） - 如果用 Zuul 或 Gateway，需单独配置路由转发，否则网关层就 404 了
真正麻烦的是混合使用 Reactor 和 Hystrix：Mono 包裹的 HystrixCommand 很容易因线程上下文丢失导致 fallback 不执行，这种链路一深，问题就藏得特别深。
