Sentinel 的 flow 规则 qps 设成 5，桶容量默认等于 qps。单条查询正常，批量接口 /api/orders/batch 一次带 100 个 id，返回 429 Blocked by Sentinel (flow limiting)，重试 3 次都失败。日志里能对上时间点，这种反而好排。
令牌桶按单次请求扣一个令牌，批量接口一次也只扣一个，调用方却把 100 条数据算成 100 次请求的额度。容量按单条接口估的，没考虑批量入口的实际工作量。这一点先确认清楚，后面就不用反复试。
curl -s -o /dev/null -w '%{http_code}' -X POST \
https://api.example.com/api/orders/batch -d @ids_100.json
# 期望 200 实际 429
围绕「令牌桶容量过小」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
处理上按这个顺序：批量接口单独配一条规则 阈值按 id 数量加权；把批量拆成每批 20 条 分 5 次发出；限流拒绝时返回剩余可重试时间 让调用方退避。
结果对不对很好判断，同一个请求从 429 变成 200，响应体里 100 条记录齐全，桶剩余令牌显示 100。