PHP生成API密钥应使用random_bytes()配合bin2hex()或URL安全Base64，长度≥32字节；密钥须加密存库、禁用明文日志；优先Bearer Header传输，服务端通过Redis缓存校验并限频；泄露时支持轮换与审计。
PHP 本身不“写”密钥，而是生成、存储、传输和验证 API 请求密钥——关键在于你用什么方式生成、放在哪、怎么校验。直接上手前先明确：这不是一个函数调用就能解决的事，而是一套前后端协同的访问控制逻辑。
用 random_bytes() 生成安全密钥
别用 md5(time().rand()) 或 uniqid()，它们可预测、熵不足，容易被爆破。PHP 7.0+ 推荐用 random_bytes() 配合 bin2hex() 或 base64_encode()：
$key = bin2hex(random_bytes(32)); // 64 字符十六进制密钥 // 或 $key = rtrim(strtr(base64_encode(random_bytes(32)), '+/', '-_'), '='); // URL 安全 Base64
- 长度建议 ≥ 32 字节（即生成后至少 64 hex 字符），避免短密钥被暴力穷举
- 生成后必须立刻存入数据库或 Redis，并关联用户/应用 ID、过期时间、权限范围
- 不要在日志、错误响应、HTTP 响应头中直接回显原始密钥
API 请求时如何传密钥（Header 还是 Query？）
优先走 Authorization Header，格式统一、不易被缓存或记录。例如：
Authorization: Bearer abcdef1234567890...
不推荐用 ?api_key=xxx，原因很实在：
立即学习“PHP免费学习笔记（深入）”；
- URL 可能被代理、CDN、浏览器历史、服务器 access_log 记录，密钥就暴露了
- GET 请求会被浏览器预加载、缓存，导致密钥意外重放
- 某些 WAF 或网关会自动过滤含
api_key的 query 参数，反而拦截合法请求
如果必须用 Query（如调试场景），务必配合短期时效签名（如 timestamp + signature），且服务端严格校验时间窗口（如 ±300 秒）。
服务端怎么验证 Bearer 密钥？
拿到 Header 中的 token 后，不能直接查数据库硬匹配——高频请求下 DB 成瓶颈，且没做防爆破。正确流程是：
- 先用
preg_match('/^Bearer\s+(.+)$/', $header, $matches)提取 token，拒绝格式错误请求 - 对 token 做长度校验（如
strlen($token) !== 64），快速失败 - 查缓存（Redis）比查 MySQL 快 10–100 倍；键名建议用
"api_key:{$token}"，值存用户 ID、权限 scope、剩余调用次数等 - 命中缓存后，再检查是否过期、是否被禁用（
is_active字段）、是否超出限频（用 Redis INCR + EXPIRE 实现） - 全程避免使用
LIKE或模糊查询，密钥字段必须建唯一索引
密钥泄露了怎么办？
没有“绝对安全”，只有“快速止损”。系统设计时就要支持：
- 后台提供密钥轮换接口（
/v1/api-key/rotate），旧密钥立即失效，新密钥即时生效 - 数据库里密钥字段必须加密存储（如用
openssl_encrypt()+ 应用级密钥），不能明文 - 所有密钥操作（创建/删除/禁用）必须记审计日志，包含操作人、IP、时间、影响范围
- 前端 SDK 或文档里禁止硬编码密钥；CI/CD 流水线中密钥必须从 Vault 或环境变量注入，而非 Git 提交
最常被忽略的一点：密钥验证逻辑一旦写进中间件，就很容易忘记加「非空校验」或「提前 return」——比如没匹配到缓存时忘了 return response('Unauthorized', 401)，结果后续代码继续执行，造成越权访问。这类逻辑漏洞不会报错，但危害极大。
