LaravelPassport优化技巧分享

Laravel Passport 的性能瓶颈几乎全部集中在高频的 Token 验证环节——每次 API 请求都直查数据库，导致高并发下数据库 I/O 崩溃、单次请求 40%+ 耗时花在 token 查询上；真正高效的解法不是弃用 Passport，而是精准将 TokenRepository 的读写迁移至 Redis 缓存：通过继承并重写 findValidToken（优先查带 revoked 状态标识的缓存 key，TTL 比过期时间少 30 秒）和 revokeAccessToken（同步清除缓存），再辅以 Redis 发布/订阅机制保障多节点缓存一致性，配合合理的索引优化与配置权衡（如 tokens_expire_in 设为 3600 秒），即可在不侵入业务逻辑的前提下，实现验证耗时断崖式下降与安全不失控的双重目标。

Passport 的性能瓶颈几乎都集中在 Token 验证环节：每次请求都查数据库，高并发下直接拖垮 DB。核心解法不是“换掉 Passport”，而是把 TokenRepository 的读写路径从 DB 挪到缓存，并控制好失效边界。

Token 验证为什么慢？看 findValidToken 的实际调用链

默认情况下，Laravel Passport 的 TokenRepository 在每次中间件校验（比如 auth:api）时，都会执行一次 findValidToken 查询——它最终落在 oauth_access_tokens 表的全字段 SELECT 上，且无复合索引支撑。哪怕加了 id 主键索引，也挡不住高频随机 ID 查询带来的磁盘 I/O 压力。

常见错误现象：SHOW PROCESSLIST 里长期堆积大量 SELECT * FROM oauth_access_tokens WHERE id = ?；Debugbar 显示单次 API 请求中 Token 查询耗时占整体 40%+。

• 必须确认你用的是 database driver（即默认方式），而非 token 或自定义 driver
• 检查 oauth_access_tokens 表是否已有 index_revoked_expires_at（Passport v11+ 自带），若没有，手动加：ALTER TABLE oauth_access_tokens ADD INDEX idx_revoked_expires_at (revoked, expires_at);
• 不要试图用 whereRaw 或视图优化这个查询——它本质是缓存场景，不是 SQL 优化场景

缓存 Token 的正确姿势：绕过 TokenRepository 还是重写它？

直接改 TokenRepository 是最稳妥的，因为所有 Passport 内部逻辑（包括 PersonalAccessTokenFactory、TransientToken）都依赖它。别用中间件或全局事件“打补丁”，那会漏掉刷新、撤销、scopes 校验等路径。

实操建议：

• 继承 TokenRepository，覆盖 findValidToken 和 revokeAccessToken 方法，在前者中先查 Cache::get("passport:token:{$id}")，未命中再查 DB 并写入缓存（TTL 设为比 expires_at 少 30 秒）
• revokeAccessToken 必须同步 Cache::forget("passport:token:{$id}")，否则已撤销 Token 可能被缓存继续放行
• 缓存 key 要包含 revoked 状态标识，例如："passport:token:{$id}:{$revoked}"，避免“已撤销但缓存未清”导致的安全缺口

config/passport.php 里哪些配置会影响缓存效果？

很多人忽略 tokens_expire_in 和 refresh_tokens_expire_in 的设置，其实它们直接决定缓存 TTL 的安全上限。设得太长，缓存失效滞后风险就高；太短，又抵消不了缓存收益。

• tokens_expire_in 建议设为 3600（1 小时），对应缓存 TTL 用 3570 秒（少 30 秒），这是多数业务可接受的权衡点
• personal_access_tokens_expire_in 如果用于 Postman 测试或管理后台，可单独设为 86400（24 小时），但它的缓存 TTL 必须独立管理，不能复用访问令牌逻辑
• 禁用 cookie session 驱动下的 Passport（即不混用 web 和 api guard），否则 TokenRepository 可能被意外绕过，缓存策略失效

最难绷的是缓存一致性——不是“加了 Redis 就快了”，而是“Token 撤销那一刻，所有节点上的缓存是否同时失效”。用 Publish/Subscribe 同步失效信号比轮询或定时清理更可靠，但这一步容易被跳过，结果就是线上偶发 401 错误或已注销用户仍能访问接口。

好了，本文到此结束，带大家了解了《LaravelPassport优化技巧分享》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！