用线程状态机+策略模式+观察者模式替代aop限流，将限流变为可感知、可编排的轻量协同机制：定义idle→checking→allowed→rejected→throttled→recovering六状态，环境类统一入口，策略解耦算法，观察者联动监控降级，threadlocal隔离状态，异步校验保低延迟。
用线程状态机 + 设计模式组合替代传统 AOP 暴力限流切面，核心是把“限流”从横切的、侵入式、全局强干预的行为，变成可感知状态、可动态切换、可按需编排的轻量协同机制。它不靠拦截所有方法再硬塞逻辑，而是让业务线程自己在关键路径上“主动申报状态”，由状态机驱动策略执行——既保实时性，又解耦、易测、可追溯。
状态机定义限流生命周期
把限流过程建模为有限状态：Idle（空闲）→ Checking（校验中）→ Allowed（放行）→ Rejected（拒绝）→ Throttled（节流中）→ Recovering（恢复中）。每个状态封装对应行为（如 Checking 调用令牌桶/滑动窗口校验；Rejected 记录告警并返回标准错误码），避免 if-else 堆砌。
环境类（如 RateLimitContext）持有当前状态引用，并提供 safeExecute(Runnable task) 等统一入口。状态切换由校验结果或超时事件触发，不依赖 AOP 的 methodSignature 匹配。
策略模式绑定具体限流算法
不同场景用不同算法，但调用方式一致：
- 高吞吐 API 接口 → 滑动时间窗（基于 ConcurrentMap + 时间戳分片）
- 下游强依赖服务 → 令牌桶（带预热与突发支持）
- 用户级操作（如发评论）→ 自定义规则策略（结合用户等级 + 历史频次 + 设备指纹）
这些策略实现统一接口 RateLimitStrategy，由状态机在 Checking 状态下调用 strategy.tryAcquire()。新增算法只需加一个 ConcreteStrategy 类，无需改切面、不碰原有 AOP 配置。
观察者模式联动监控与降级
当状态进入 Rejected 或 Throttled 时，自动通知多个观察者：
- MetricsObserver：上报 QPS、拒绝率、平均等待延迟到 Prometheus
- AlertObserver：连续 5 次拒绝触发企业微信告警
- FallbackObserver：触发本地缓存兜底或返回静态响应体
解耦了限流逻辑与运维动作，也避免在 @Around 切面里混写业务监控代码，提升可测试性。
线程局部状态 + 异步状态更新防干扰
每个请求线程通过 ThreadLocal
这样既满足低延迟要求（P99
