passport性能瓶颈在token验证环节，需将tokenrepository读写迁至缓存并控制失效边界；核心是继承tokenrepository覆盖findvalidtoken和revokeaccesstoken，结合带revoked标识的缓存key与redis发布订阅保障一致性。
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%+。
- 必须确认你用的是
databasedriver（即默认方式），而非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 必须独立管理，不能复用访问令牌逻辑 - 禁用
cookiesession 驱动下的 Passport（即不混用web和apiguard），否则TokenRepository可能被意外绕过，缓存策略失效
最难绷的是缓存一致性——不是“加了 Redis 就快了”，而是“Token 撤销那一刻，所有节点上的缓存是否同时失效”。用 Publish/Subscribe 同步失效信号比轮询或定时清理更可靠，但这一步容易被跳过，结果就是线上偶发 401 错误或已注销用户仍能访问接口。
