PHP防AI接口滥用需session+IP双重限频、JWT细粒度权限校验、UA/缓存头识别及异步日志告警，缺一环即失效。
PHP中用session+IP限频防AI接口滥用
直接封IP或只靠token基本拦不住批量调用，必须结合用户会话状态与请求频次做双重约束。session能绑定真实登录态，IP限频则兜底未登录或绕过登录的场景。
常见错误是只校验$_SESSION['user_id']就放行，结果攻击者复用合法session ID发起洪流请求；或者只按IP计数，忽略同一IP下多个合法用户共存的情况。
- 在接口入口处先调用
session_start()，检查$_SESSION['user_id']和$_SESSION['role']是否有效且匹配当前接口权限等级 - 对每个
$_SERVER['REMOTE_ADDR']+$_SESSION['user_id']（若存在）组合，用Redis记录1分钟内请求次数，键名如rate:ip:192.168.1.100:user:123 - 若无session（如API token直连），仅用
rate:ip:192.168.1.100:anon计数，阈值设得更低（比如5次/分） - Redis过期时间设为60秒，用
INCR+EXPIRE原子操作，避免竞态导致超限
用JWT声明+中间件校验用户角色而非硬编码权限
把权限逻辑写死在接口里，后期加个“管理员可导出”就得改多处代码。JWT的scope或自定义roles字段配合中间件，才能让权限变更不碰业务逻辑。
典型翻车点：解析JWT后只验证签名和过期时间，却没校验payload['roles']是否包含'ai:generate'这类细粒度动作标识；或把角色数组存在$_SESSION里，导致登出后JWT仍可用。
立即学习“PHP免费学习笔记（深入）”；
- 签发JWT时，在payload中嵌入
"roles": ["user", "ai:basic"]，不要只写"role": "user" - 中间件里用
firebase/php-jwt解码后，检查$token->roles是否包含当前接口所需的最小权限，例如in_array('ai:generate', $token->roles) - 禁止将JWT payload持久化到session——每次请求都重新解析并校验，避免token被吊销后仍生效
- 敏感操作（如批量调用模型）额外要求
scope含'ai:batch'，并在数据库里配好各角色对应scope白名单
接口响应头强制禁用缓存+埋点识别非浏览器UA
AI爬虫常带User-Agent: python-requests或空UA，又爱缓存响应体反复刷接口。光靠后端限流不够，前端配合也能筛掉一部分低智滥用。
容易忽略的是Nginx或CDN可能缓存了200响应，导致攻击者根本没打到PHP层；还有部分爬虫伪造Chrome UA但缺失Sec-Ch-Ua等现代浏览器特征头。
- PHP脚本开头加
header('Cache-Control: no-store, no-cache, must-revalidate, max-age=0');，确保CDN和客户端不缓存 - 检查
$_SERVER['HTTP_USER_AGENT']是否匹配正则/^(python-requests|curl|httpie|Go-http-client|bot|crawl|scan)/i，命中则记录日志并返回429 - 对非空UA但缺失
$_SERVER['HTTP_SEC_CH_UA']或$_SERVER['HTTP_ACCEPT'] !== 'application/json,*/*'的请求，提高限频权重（比如计为2次） - 别依赖
$_SERVER['HTTP_REFERER']——它极易伪造，仅作辅助参考
MySQL里记录调用日志并触发异常行为告警
光拦截不够，得知道谁在什么时候干了什么。日志不落地，就无法回溯是内部员工误用还是外部撞库；没有统计维度，就发现不了“某个用户每小时调用3000次文生图但从未调用对话接口”的异常模式。
最常踩的坑是把日志写进主业务库还用INSERT ... SELECT查用户表，拖慢核心接口；或者只记user_id，结果共享账号时无法定位到具体设备或Token。
- 单独建
ai_api_log表，字段至少含user_id、token_hash（SHA256前8位）、endpoint、status_code、cost_ms、created_at - 用
PDO::exec()异步插入，不等待返回，失败也不中断主流程——日志只是辅助，不能拖垮接口 - 每5分钟跑一次
SELECT user_id, COUNT(*) FROM ai_api_log WHERE created_at > NOW() - INTERVAL 5 MINUTE GROUP BY user_id HAVING COUNT(*) > 200，结果推企业微信机器人 - 对
status_code = 429的记录加索引，方便快速查某IP/用户被限频原因
真正难的不是写几行限流代码，而是把session生命周期、JWT刷新机制、Redis连接池、日志采样率这些点串成一条可控链路。任意一环松动，比如Redis挂了降级成内存计数，或JWT过期时间设成7天却没实现黑名单，都会让整套控制形同虚设。
