TP5.1无内置限流功能，需基于Redis缓存手动实现IP与手机号双维度限流：IP限流前置至中间件层用INCR+EXPIRE原子操作，手机号频控须绑定业务key并确保Redis原子性，且必须配置Nginx透传头与trusted_proxies获取真实IP。
TP5 里没有现成的限流函数，得自己写逻辑，别指望 think\facade\RateLimit 这种类——它根本不存在。
为什么不能直接用 TP5 自带的限流能力
ThinkPHP5 官方未提供任何内置限流组件或 Facade 类。所谓“TP5 限流函数”是常见误解，源于把 TP6/TP8 的生态功能错配到 TP5 上。TP5 的核心设计聚焦于 MVC 和路由，流量控制完全交由开发者自行实现，依赖 Session、Cache 或外部存储（如 Redis）来维护计数状态。
- 所有“限流中间件”“
RateLimit::check()”调用都会报Class "think\facade\RateLimit" not found - TP5 的
think\Cache是可用的，但需手动构造键名、设置过期、做原子增减——没有封装好的increment()带 TTL 的语义 - Session 方案在并发高时容易失效（PHP 默认文件 Session 有锁），且无法跨服务器共享
最实用的 TP5 限流函数写法（基于 Cache）
用 think\Cache + 时间窗口计数，简单可靠，适配绝大多数后台接口场景。关键点不是“怎么写函数”，而是“怎么避免计数漂移和并发冲突”：
- 缓存键必须包含 IP + 路由标识（如
'rate_limit_' . $ip . '_' . md5($request->url())），否则不同接口会互相干扰 - 不要用
Cache::inc()—— TP5 的inc()不支持设置初始值和过期时间，得先get()再set()，中间可能被并发请求覆盖 - 正确做法：用
Cache::remember()封装初始化逻辑，或用Cache::store('redis')->inc()（仅当已配置 Redis 缓存驱动时） - 示例片段（放在公共函数文件或基类中）：
function checkRateLimit($ip, $keySuffix = '', $maxCount = 10, $windowSeconds = 60) {
$cacheKey = 'rate_limit_' . $ip . '_' . $keySuffix;
$count = \think\Cache::get($cacheKey, 0);
if ($count >= $maxCount) {
return false;
}
\think\Cache::set($cacheKey, $count + 1, $windowSeconds);
return true;
}
调用前确保 $ip 已通过 get_client_ip() 或 $_SERVER['REMOTE_ADDR'] 获取并做了基础校验（防伪造 X-Forwarded-For）。
TP5 中绕不开的坑：IP 获取不准、缓存驱动没配好
限流失效的多数原因不在逻辑，而在环境配置和边界处理：
- 没配反向代理时，
$_SERVER['REMOTE_ADDR']是 Nginx 的地址（如 127.0.0.1），不是真实用户 IP；必须检查$_SERVER['HTTP_X_FORWARDED_FOR']并白名单可信代理（如['192.168.1.1', '10.0.0.1']），否则限流对象错乱 - 默认文件缓存（
type=file）在高并发下会因文件锁导致计数漏增，Cache::get()返回旧值；必须切到 Redis 驱动（type=redis）并确认redis.host可连通 - 没设
Cache::tag()或命名空间，不同模块的限流键混在一起，比如后台登录页和 API 接口共用同一组 key，相互挤占额度
真正难的不是写出一个能跑的限流函数，而是让它的计数在分布式部署、代理穿透、缓存失效、并发写入这些真实条件下依然可预期。TP5 不帮你兜底，每一处 Cache::set() 都得想清楚：这个 key 会不会被别的请求改？过期时间是不是真按窗口算？IP 是不是已经被中间件污染？
