限制api访问频率与配置白名单需分层拦截：先通过ip白名单前置过滤来源，再强制jwt或api key身份验证，最后按角色授权并实施速率限制，辅以日志审计与熔断机制。
限制 API 接口的访问频率与配置白名单，不是加个开关就能生效的事，关键在于分层拦截、精准识别、统一管控。核心要解决三个问题：谁来调（身份）、从哪来（来源）、调多少（频次）。
IP 白名单必须前置拦截
白名单不是“放行后再检查”，而是第一道闸门。它应在请求进入业务逻辑前就完成过滤，避免无效请求消耗资源。
- 在反向代理层（如 Nginx）用
allow/deny规则直接拒绝非白名单 IP，最轻量高效 - 若走应用层控制，需确保
$request->ip()获取的是真实客户端 IP —— 必须配置好TrustProxies中间件，否则反代后看到的全是127.0.0.1 - 不要把白名单硬编码在路由闭包里跳过限流，这会绕过中间件生命周期，审计和日志都会丢失
速率限制得区分对待白名单 IP
白名单 IP 不等于“免审”，但可以免限流。标准 throttle 中间件不支持条件跳过，必须自定义逻辑。
- 继承
ThrottleRequests，重写resolveRequestSignature()方法 - 对白名单 IP 返回固定键（如
"throttle_bypass_192.168.1.100"），让它永远不触发计数器 - 避免用
if (in_array(...)) return;直接中断中间件，会导致后续中间件（如日志、鉴权）不执行
身份验证不能和白名单混为一谈
IP 白名单只管“从哪来”，不管“是谁”。攻击者可能从合法 IP 发起未授权调用，所以必须叠加身份校验。
- JWT 或 API Key 必须强制携带，且在校验通过后才进入权限判断环节
- 建议组合使用：白名单校验 → JWT 解析 → RBAC 角色权限检查 → 接口级操作授权
- 例如 MogFace 或 M2LOrder 的实践：先验 IP，再验 Bearer Token，最后查该 token 是否有
face:detect权限
监控和兜底机制不能少
白名单+限流只是手段，不是终点。没有可观测性，就等于没防护。
- 所有被拒绝的请求（IP 拒绝、Token 过期、超频）都要记录完整上下文：IP、User-Agent、时间戳、接口路径
- 对高频失败的白名单 IP 做标记，可能是密钥泄露或内部服务异常，需人工介入
- 设置紧急熔断开关，比如某接口 1 分钟内 500 错误超 100 次，自动临时关闭该路由
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
