Flask-Limiter的key_func必须精准构造唯一标识：按IP需处理反代（X-Real-IP fallback）、按用户须用认证后ID（如g.user.id）、按参数需拼接endpoint+args，禁用未校验输入和耗时操作，且须配Redis避免内存降级失效。
Flask-Limiter 的 key_func 怎么写才真正精准？
限流不准，八成是 key_func 没写对。默认按 IP 限流（get_ipaddr），但实际中常需按用户 ID、API 路径+参数组合、甚至请求头里的 X-App-Version 区分策略。直接用 request.remote_addr 在 Nginx 反代后会变成 127.0.0.1，必须改用 request.headers.get("X-Real-IP") or request.remote_addr。
实操建议：
- 需要按登录用户限流：确保已认证，从
g.current_user.id或get_jwt_identity()（配合 Flask-JWT-Extended）取值，别用未校验的request.args.get("user_id") - 要区分 GET /api/items?id=1 和 /api/items?id=2：在
key_func中显式拼接request.endpoint + request.args.get("id", "")，否则两者共用同一计数器 - 避免在
key_func里做数据库查询或耗时操作——它每次请求都执行，会拖慢所有流量
怎么给不同接口配不同限流规则？
一个应用里，健康检查接口（/health）该放开，支付回调（/webhook/payment）要严控，用户资料接口（/user/profile）按用户 ID 限流——全靠装饰器参数动态控制。
实操建议：
- 用字符串形式传规则，如
@limiter.limit("100 per day")或@limiter.limit("5 per minute", key_func=uid_key)，不要写死成变量名 - 路由级配置优先于全局配置：全局设
"1000 per day"，再在敏感接口上加更严的@limiter.limit("3 per minute")，后者生效 - 注意
per_minute/per_hour等单位是 Flask-Limiter 内置别名，本质解析为1/minute，不支持自定义单位如per_request
Redis 后端连不上或计数异常怎么办？
报错 ConnectionError: Error 111 connecting to localhost:6379 或限流完全不触发，大概率是后端没配对，或者 Redis 实例没启、密码不对、ACL 权限不足。
实操建议：
- 初始化 Limiter 时显式传
key_prefix，比如key_prefix="flask-limiter:"，方便在 Redis CLI 里用KEYS flask-limiter:*检查键是否存在 - 如果用 Redis 密码，URL 必须带
redis://:password@localhost:6379/0，漏掉冒号或斜杠会导致静默降级到内存存储（memory），看似运行但不持久 - 内存后端（
memorystore）仅用于开发调试，多进程部署下各进程计数独立，生产必须用 Redis 或 Memcached
为什么 OPTIONS 预检请求也被限流了？
CORS 预检请求被拦住，前端报 429 Too Many Requests，是因为 Flask-Limiter 默认对所有方法生效，包括 OPTIONS。而浏览器发预检不带认证头、不走业务逻辑，不该计入用户额度。
实操建议：
- 在路由注册时排除
OPTIONS：用@app.route("/api/data", methods=["GET", "POST"])显式声明，别用methods=["*"] - 或在
key_func中加判断：if request.method == "OPTIONS": return "skip-limiting"，让其命中一个永不超限的 key - 更稳妥的是用
@limiter.exempt装饰器标记预检路由，但得确保它在@limiter.limit之前执行
Flask-Limiter 的精度不在“能限”，而在 key 的构造粒度和后端一致性；跨服务部署时，Redis 连接池配置、超时时间、连接复用这些细节，比规则语法更容易导致线上限流失效。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
