最常见的原因是Limiter实例未正确初始化或未绑定到Flask应用，必须显式调用init_app()且顺序需在创建app之后、注册路由之前。
为什么直接用 @limiter.limit 可能没效果
最常见的现象是：加了装饰器，但请求依然能无限刷接口。根本原因通常是 Limiter 实例没正确初始化或没绑定到 app。
Flask-Limiter 不会自动接管 Flask 应用，必须显式调用 init_app()，且顺序不能错——得在创建 app 之后、注册路由之前完成。
- 错误写法：
limiter = Limiter(key_func=get_remote_address)单独定义后就不管了 - 正确写法：
limiter = Limiter(key_func=get_remote_address, app=app, default_limits=["200 per day"])或分两步：limiter.init_app(app) - 若用工厂模式，
init_app()必须在create_app()内调用，不能只在模块顶层实例化
如何按用户 ID 而不是 IP 限流
默认的 get_remote_address 只认 IP，对登录态接口不适用。关键在于重写 key_func，从请求中提取稳定标识。
常见做法是从 Header（如 X-User-ID）或 Token 解析用户 ID，但要注意 fallback：未认证用户必须返回可区分的 key，否则所有人共享一个配额。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 推荐写法：
def get_user_or_ip(): user_id = request.headers.get("X-User-ID") if user_id: return f"user_{user_id}" return request.remote_addr - 避免直接用
session.get("user_id")：若 session 存 Redis 且未配置 sticky session，可能因负载均衡导致 key 不一致 - JWT 场景下，建议在中间件里解析 token 并设
g.user_id，再由key_func读取，避免重复解析
per minute 和 per second 的实际行为差异
看起来只是时间单位不同，但底层滑动窗口逻辑会让它们表现迥异。Flask-Limiter 默认用的是固定窗口（fixed window），不是滑动窗口（sliding window）。
比如设 "10 per minute"，系统每分钟整点重置计数器；而 "10 per second" 是每秒重置。这会导致突发流量被“削峰”得非常生硬——第 59 秒发 10 次，第 0 秒又发 10 次，实际 2 秒内 20 次，但完全合法。
- 需要平滑限流？得换存储后端（如 Redis + lua 脚本）并启用
in_memory_fallback=False，但 Flask-Limiter 官方不直接支持滑动窗口 - 更现实的方案：用
"600 per hour"替代"10 per minute"，降低窗口敏感度 - 注意：SQLite 等本地存储不支持并发计数，多进程部署时必须用 Redis 或 Memcached
429 响应体怎么自定义而不崩掉
直接在视图里 return jsonify(...), 429 不行——限流触发发生在路由执行前，靠 Flask 错误处理器拦截才是正路。
但 @app.errorhandler(429) 拿不到被限流的路由信息，容易返回笼统提示。更可控的方式是用 on_limit 回调 + 自定义异常。
- 注册时传参：
limiter = Limiter( on_limit=lambda: abort(429, description="Too many requests, slow down.") ) - 或者用
@limiter.request_filter先过滤掉健康检查等免限流路径，避免误判 - 切记不要在
on_limit里做耗时操作（如写日志到慢盘），它在每次限流检查时都执行
