42 动态令牌桶与配额管理：按套餐等级分配资源开篇故事上周，一个做AI视频分析平台的客户找到我，说他们的RT-DETR推理服务遇到了一个棘手问题。“我们给免费用户每天100次调用，付费用户不限量。但免费用户经常在凌晨批量刷请求——他们用脚本定时调用，把100次额度在1分钟内全部用完。结果付费用户早上8点上班时，发现系统响应变慢了。”客户的技术负责人无奈地说。我问他：“你们现在怎么做配额管理的？”“简单粗暴。每个用户一个计数器，到上限就返回429。但免费用户集中突发时，会把推理节点的连接池占满，付费用户的请求也被阻塞了。”这正是很多团队容易踩的坑——配额管理不等于限流，两者需要协同工作。上一篇我们实现了动态令牌桶来限流，但限流只关心“请求速率是否超标”，而配额管理关心的是“用户是否还有额度”。两者是不同维度的问题，但必须结合起来才能做到真正的资源隔离。痛点拆解：配额+限流的常见错误错误认知1：配额检查放在限流之后很多人的第一直觉是：先让令牌桶限流，再检查配额。但这样会导致配额检查形同虚设。# 反例：配额检查在限流之后classWrongQ