文章目录约束设计三级分流队列JSONL 文件锁Digest每小时整理一次配额三层防线为什么不用消息队列中间件总结约束通过官方通道给微信发消息有个硬约束全天主动发送上限 10 条。超过就发不出去。10 条什么概念系统里跑着几十个定时任务邮件分拣、考研监测、福利领取、账号监控……每个都想推一条分分钟超标。设计三级分流┌─ 紧急 ──→ 立刻推送 待推送事项 ──┤ └─ 非紧急 ─→ 入队 → 定时 digest 合并发送紧急标准今天/明天内必须处理错过即实质损失截止类提醒报名、缴费、兑换码先到先得审核不通过需补材料账号异常非紧急重要但可以等简报、周报、价格政策变化等。紧急的直接调发送脚本立刻发非紧急的写入队列文件等 digest 任务整理。队列JSONL 文件锁队列就是个 JSONL 文件每行一条{ts:2026-10-15T14:30:00,source:inbox-scan,text:内容,sent:false}写入时加文件锁fcntl.flock防止多个任务同时写坏文件。实现很简单30 行 Python。Digest每小时整理一次digest 任务每小时跑一次触发条件满足一条才发队列中待发送 ≥ 3 条或最早一条等待 ≥ 3 小时整理步骤配额检查先数今天已发了几条≥ 8 条就跳过给紧急推送留 2 条余量去重内容相似的合并为一条排序按重要性排压缩200 字以内一条发完实在放不下最多分 2 条发送成功后已发送条目移出队列、记入已发送日志失败的不重试留到下次。配额三层防线超标是最不能接受的做了三层防线发送脚本内置检查每次发送前数今天的发送日志≥ 10 条直接拒绝digest 预留余量digest 在 8 条就停手留 2 条给紧急推送审计日志每次发送记一行方便事后对账为什么不用消息队列中间件想过用 Redis/RabbitMQ但就一个 JSONL 文件能解决的事没必要引入服务文件锁在单机场景够用了少一个依赖少一个故障点总结这套机制跑下来最大的体会是约束越硬设计越要简单。10 条的限制逼着我把什么值得打扰用户想清楚——紧急的定义、合并的规则、余量的预留每个数字背后都是一次取舍。给做类似系统的建议先定配额再定分级最后才是实现。顺序反了代码写得再漂亮也是错的。以上全文完。如果这篇文章对你有帮助欢迎点赞收藏也欢迎在评论区交流你的做法。欢迎关注我的 CSDN 博客https://blog.csdn.net/2301_80281820