Hystrix 在 Spring Boot 2.0+ 中失效是因为 Netflix 停止维护，Spring Cloud Greenwich 起移除自动装配；@HystrixCommand 不生效主因是缺失 hystrix-javanica、未启用请求上下文、调用未走代理或 Actuator 端点未正确暴露。
为什么 Hystrix 在 Spring Boot 2.0+ 里直接失效了
因为 Netflix 官方已停止维护 Hystrix，Spring Cloud 自 Greenwich 版本起默认移除了对它的自动装配支持。你加了 @EnableCircuitBreaker、写了 @HystrixCommand，但断路器根本不触发——不是代码写错了，是依赖根本没加载。
- Spring Boot 2.1+ + Spring Cloud Greenwich 及之后版本：
spring-cloud-starter-netflix-hystrix不再包含 starter 自动配置，必须手动启用HystrixCircuitBreakerConfiguration - 真正起作用的类是
HystrixCommand（非注解），而@HystrixCommand注解依赖hystrix-javanica的 AOP 织入，缺spring-aop或字节码增强失败时静默降级为普通方法 - 常见错误现象：
HystrixRuntimeException没抛出、fallback 方法从不执行、HystrixCommandMetrics始终为 0
怎么让 @HystrixCommand 在新项目里真正生效
不是加个依赖就行，得补全三块拼图：字节码增强、命令注册、指标暴露入口。
- 必须引入
hystrix-javanica（注意不是hystrix-core单独用），且确保它和spring-aop共存；Gradle 中若用了spring-boot-starter-aop，一般没问题 -
@HystrixCommand方法不能是private或static，调用必须走 Spring 代理（即不能在同类内直接 this.method() 调用） - 需要显式开启 Hystrix 请求上下文：在 Web 层入口（如
@RestController方法）或 Filter 中调用HystrixRequestContext.initializeContext()，否则ThreadLocal隔离失效，fallback 和超时统计全乱 - 示例关键配置：
spring: cloud: circuit: hystrix: enabled: true management: endpoints: web: exposure: include: hystrix.stream
Hystrix Dashboard 连不上 / stream 404 怎么查
/actuator/hystrix.stream 返回 404 或空响应，大概率是 Actuator 端点没对齐或过滤器拦截了 SSE 流。
- 确认 Spring Boot 版本对应端点路径：
Boot 2.0–2.2是/actuator/hystrix.stream，Boot 2.3+默认关闭了所有非敏感端点，需显式开放：management.endpoints.web.exposure.include=hystrix.stream,health,info - Hystrix Stream 是 Server-Sent Events（SSE），必须用
text/event-stream响应头；Nginx 或网关若未透传该 header，Dashboard 就连不上——检查响应头是否有Content-Type: text/event-stream - 如果用了 Spring Security，要放行
/actuator/hystrix.stream，且不能要求认证（Dashboard 是前端直连，不带 token） - 本地调试可直接 curl：
curl -H "Accept: text/event-stream" http://localhost:8080/actuator/hystrix.stream，看到持续输出事件流才算通
替代方案比硬扛 Hystrix 更实际
强行在新项目里拉起 Hystrix，等于在修一台停产的发动机——能转，但备件难找、文档断档、没人敢改。
立即学习“Java免费学习笔记（深入）”；
- Resilience4j 是当前事实标准：轻量、无反射、函数式 API，和 Spring Boot 2.x 天然契合，
@Retry、@CircuitBreaker注解开箱即用，metrics 默认对接 Micrometer - 如果你只是想防雪崩，
spring-cloud-openfeign内置的@FeignClient(fallback = ...)已足够覆盖 80% 场景，无需引入额外容错框架 - Hystrix 的线程池隔离模式在现代容器环境下反而成负担（每个 command 开独立线程池 → GC 压力大、线程数难控），信号量隔离又和 Spring MVC 的线程模型冲突，容易卡死
真正麻烦的从来不是配一个断路器，而是搞清服务间依赖拓扑、定义合理的 fallback 语义、以及让监控数据能真实反映熔断状态——这些事，换 Resilience4j 也得做，但至少不用和过期的 ClassLoader 机制较劲。
