在 Node.js 环境下，针对传入的 HTTP 请求，你会采用哪些具体技术方案来实施限流？请说明不同方案的适用场景。

回答思路

1. 【回答框架 1】限流的核心是控制单位时间内的请求速率，避免过载。常见算法有计数器固定窗口、滑动窗口、令牌桶和漏桶。固定窗口实现简单但存在临界问题；滑动窗口通过细分子窗口减少毛刺；令牌桶允许一定突发流量，按恒定速率补充令牌；漏桶强制恒定输出速率，适合追求平稳的场景。
2. 【回答框架 2】在 Node.js 中可直接基于内存实现，例如用 Map 记录每个键（如 IP 或用户 ID）对应的请求时间戳数组，配合滑动窗口进行裁剪判断。更简单的方式是使用 lru-cache 计数器或借助 Redis 的 INCR 和 EXPIRE 实现固定窗口，用 ZSET 实现滑动窗口或令牌桶。
3. 【回答框架 3】若选用第三方库，如 express-rate-limit，它底层默认采用固定窗口，也可配置为滑动窗口。对于更复杂的分布式限流，建议使用 Redis 或 Nginx 层方案。选择策略需权衡精度、内存占用与实现复杂度，例如单机高并发优先使用令牌桶或滑动窗口。
4. 【回答框架 4】实现时需注意时间精度、代码原子性（尤其在 Redis 环境下使用 Lua 脚本）以及限流参数的动态配置。无论何种方案，都要明确返回的 HTTP 状态码（如 429）和响应头（如 Retry-After）以便客户端处理。
5. 【回答框架 5】性能上，内存方案吞吐远高于 Redis，但多实例时无法精确共享计数。一般建议结合业务特点，采用混合策略，如网关层用令牌桶，业务层用计数限流，并配合监控告警。
6. 【关键点 1】固定窗口存在临界流量双倍放大的风险。
7. 【关键点 2】滑动窗口适用于对突发容忍度低的场景。
8. 【关键点 3】令牌桶允许突发，适合接口有波峰的业务。
9. 【关键点 4】Redis 方案适合分布式环境，需保证原子性。
10. 【关键点 5】限流策略需与业务预期和部署形态匹配。
11. 【易错点 1】不能忽略多实例部署时内存计数的孤立问题。
12. 【易错点 2】使用 Redis 时若不用 Lua 脚本可能出现超限误判。
13. 【易错点 3】缺乏对限流反馈头（如 Retry-After）的处理会降低客户端友好度。