PHP文生图接口必须基于用户身份（API Key > User ID > Session ID）做限流，因IP限流无法区分内网用户与爬虫，且易被代理绕过；应使用Redis ZSET+Lua实现滑动窗口，键名带业务前缀，避免误限与内存泄漏。
直接说结论：PHP 文生图接口必须做用户级限流，不能只靠 IP 或简单时间窗；否则容易被批量调用拖垮模型服务，且无法区分真实用户与爬虫。
为什么文生图接口特别需要用户限流
文生图（如 Stable Diffusion API 封装）本质是 CPU/GPU 密集型任务，一次请求可能耗时 2–10 秒、占用数百 MB 显存。如果只按 $_SERVER['REMOTE_ADDR'] 限流，会出现以下问题：
- 公司内网或校园网所有用户共享一个出口 IP，正常用户集体被封
- 恶意用户换代理 IP 就能绕过，而你根本没记录是谁在调用
- 未登录用户无法识别，已登录用户却和游客共用同一计数器，体验割裂
所以必须绑定业务身份——比如 $user_id（登录态）、$api_key（开发者凭证）或 $session_id（临时会话），三者优先级：API Key > User ID > Session ID。
用 Redis 实现用户限流的最小可靠写法
别用 lLen + lPush 手动维护时间戳列表（易漏删、不原子、难 debug），直接上 Redis 的 ZSET + Lua 脚本保证滑动窗口精度。核心逻辑如下：
立即学习“PHP免费学习笔记（深入）”；
- 键名格式统一为
rate_limit:gen_image:{identifier}，其中{identifier}是$api_key或$user_id - 每次请求用当前时间戳（秒级）作为
score，随机字符串作member写入ZADD - 用 Lua 脚本原子执行：移除窗口外旧记录（如 60 秒前），再
ZCARD统计剩余请求数 - 超限时返回
429，并带上Retry-After: 30响应头（单位秒）
示例 Lua 脚本（保存为 sliding_window.lua）：
local key = KEYS[1]
local window = tonumber(ARGV[1])
local max = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
<p>redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local count = redis.call('ZCARD', key)</p><p>if count < max then
redis.call('ZADD', key, now, ARGV[4])
redis.call('EXPIRE', key, window + 10)
return 1
else
return 0
endPHP 中调用：$allowed = $redis->eval($lua_script, [$key, 60, 30, time(), uniqid()], 1) === 1;
ThinkPHP/Laravel 框架里怎么避免踩坑
框架自带的 throttle 中间件默认只认 IP，对文生图场景基本不可用。必须手动干预：
- ThinkPHP：重写
getLimitedKey()方法，把$request->header('X-API-Key')或$request->user()?->id拼进缓存 key，而不是依赖$request->ip() - Laravel：不要直接用
throttle:60,1，改用RateLimiter::attempt()并传入自定义 key，例如'gen_image_'.$request->user()->id - 关键细节：Redis 键必须带业务前缀（如
gen_image_），否则和登录、短信等其他限流 key 混在一起，导致误限 - 测试时用
curl -H "X-API-Key: abc123" http://api.example.com/v1/generate，别只测未带 header 的请求
容易被忽略的三个硬伤点
实际部署中最常翻车的地方不是算法，而是这些细节：
- Redis 连接池没配好，高并发下
connect()阻塞，反而让限流模块自己先挂掉 - 没校验
X-API-Key是否真实存在且未过期，就直接拿它当限流 key，导致空 key 泛滥、内存暴涨 - 响应头没设
X-RateLimit-Remaining和Retry-After，前端无法友好降级或排队，只会疯狂重试
真正稳的文生图限流，80% 功夫花在 key 的唯一性、存储可靠性、错误兜底上，而不是纠结用令牌桶还是滑动窗口。
