hyperf默认限流不等于sentinel流量整形，因其ratelimit仅支持简单计数限流，无队列缓冲、预热曲线及系统负载感知，也不支持dashboard动态联动；而sentinel提供可控延时、实时规则推送与精细化流量控制能力。
Sentinel 在 Hyperf 中不是开箱即用的，必须手动集成并针对性配置流量整形策略。直接依赖 hyperf/sentry 或默认限流中间件无法启用排队等待、预热启动等核心能力——这些功能依赖 Sentinel 的 FlowRule 控制器和实时规则推送机制。
为什么 Hyperf 默认限流不等于 Sentinel 流量整形
Hyperf 自带的 RateLimit 组件仅支持令牌桶/漏桶的简单计数限流，没有队列缓冲、无预热曲线、不感知系统负载，也无法与 Sentinel Dashboard 动态联动。而真实突发流量场景（如秒杀预热、缓存击穿后请求洪峰）需要的是「可控延时」而非「粗暴拒绝」。
常见错误是：在 config/autoload/rate_limit.php 里调高 limit 和 interval，结果压测时仍大量 503 Service Unavailable ——这说明限流没生效或策略错配。
接入 Sentinel 必须补全的 3 个关键动作
缺一不可，否则 @SentinelResource 注解无效、规则不加载、监控面板为空：
- 在
composer.json中显式添加alibaba/sentinel-php（注意：不是 Java 版本，PHP 生态需用官方维护的sentinel-php客户端，非社区移植版） - 启动时注册
Sentinel的Command和WorkerStartCallback，确保每个 worker 进程都初始化SentinelContext - 在
config/autoload/sentinel.php中配置dashboard地址和app_name，且该app_name必须与Sentinel Dashboard中注册的应用名完全一致（区分大小写、空格）
排队等待 vs 预热启动：选错就等于没防护
两者适用场景截然不同，混用会导致规则失效或服务更脆弱：
-
排队等待（
RuleConstant::CONTROL_BEHAVIOR_RATE_LIMITER）：适合下游强依赖型操作，比如调第三方支付接口、写审计日志。必须设置maxQueueingTimeMs（建议 ≤ 500），否则请求在队列中积压太久，用户已放弃，服务还在处理“僵尸请求” -
预热启动（
RuleConstant::CONTROL_BEHAVIOR_WARM_UP）：只对冷启动有效，比如服务发布后首分钟。需配合warmUpPeriodSec（通常设为 10–30 秒）和足够高的thresholdCount。若把该策略用在日常高并发接口上，QPS 会人为压低，反而放大延迟
示例错误配置："controlBehavior": 1（即排队等待）但未设 maxQueueingTimeMs → 规则加载失败，控制台报 Invalid rule: queueing time not set；又或者在 createOrder 方法上误用预热策略，导致促销开始时 QPS 被压制在 20，远低于实际承载能力 2000。
Hyperf + Sentinel 的真实瓶颈常在连接层
即便 Sentinel 规则生效，Hyperf 的协程池、数据库连接池、HTTP 客户端连接池仍可能先于限流规则崩溃。典型现象是：Dashboard 显示 QPS 稳定在阈值内，但 curl 大量超时、mysql 报 Too many connections。
必须同步调整：
-
config/autoload/database.php中pool.max_connections≥Sentinel设置的 QPS × 平均 DB 耗时（秒）× 1.5 -
config/autoload/server.php中settings.worker_num不宜过小（建议 ≥ CPU 核数 × 2），否则协程调度阻塞，Sentinel的滑动窗口统计失真 - 所有外部 HTTP 调用必须使用
Hyperf\HttpClient\CoroutineHttpClient并配置max_connections_per_host，避免被Sentinel放行的请求在连接建立阶段就卡死
最易被忽略的一点：Sentinel 的滑动时间窗口默认是 1 秒，而 Hyperf 的协程调度精度在毫秒级，若业务方法内有 co::sleep(200) 类长耗时操作，会导致同一窗口内统计的通过请求数虚高——看起来没超限，实际线程/协程早已打满。
