给 Express API 加上限流

前言

从安装存储层讲起，覆盖代理配置和基于 Redis 的分布式限流，附上响应示例和压测验证。

常见的翻车姿势

跳过这一步的团队，通常会踩中三种坑：

• 优化了一个没人同意要动的数字。
• 照抄了约束完全不同的项目的方案。
• 一直推迟决策，直到反悔的代价高得吓人。

建议的切入方式

1. 用用户的语言，一句话讲清楚问题。
2. 选择一个每周都能度量的信号，而不是只在上线当天看一眼。
3. 给小实验设定时间盒；两天的 spike 胜过两周的辩论。

小结

如果 Express.js 教会了我们什么，那就是「无聊的一致性」打赢「聪明的一次性方案」。把学到的东西带回团队，别让它变成口口相传的都市传说。