密钥过期通过比对当前时间与exp字段判断：exp必须为Unix时间戳整数，PHP用time()校验，需确保其存在、为数字且服务端时间准确；Redis中建议用SETEX自动过期。
密钥过期怎么判断：看 exp 字段是否已过时
JWT 或自定义 token 中的密钥（或 token 本身）是否过期，核心就一条：比对当前时间与 exp（expiration time）字段。PHP 里直接用 time() 就行，别用 date('U') 或 strtotime('now') —— 它们本质一样但多一层函数调用，没优势还可能因时区出错。
关键点：
-
exp必须是 Unix 时间戳（整数），不是字符串格式的日期 - 务必校验
exp是否存在且为数字，否则未设过期时间的 token 可能被误判为“已过期” - 服务端时间必须准确，NTP 同步建议开启；若用 Docker 容器，注意宿主机与容器时钟偏差
PHP 实现密钥失效检查：三步完成验证
不依赖第三方库也能安全验证。以一个简单 JWT payload 为例：
$payload = json_decode(base64_decode($parts[1]), true);
if (!isset($payload['exp']) || !is_numeric($payload['exp'])) {
throw new Exception('Missing or invalid exp claim');
}
if ($payload['exp'] < time()) {
throw new Exception('Token expired');
}
注意：
立即学习“PHP免费学习笔记（深入）”；
- 别在验证前就
json_decode整个 JWT —— 先 base64 解码 header 确认算法合法，再解 payload，最后验签名。跳过签名验证直接读exp是严重安全隐患 - 如果密钥是存储在数据库里的（比如 API key 表含
expires_at字段），查库时直接加WHERE expires_at > NOW() AND is_active = 1，避免 PHP 层二次判断 - 缓存中存的密钥（如 Redis）建议用
SETEX设置自动过期，而非靠 PHP 判断——减少逻辑耦合，也防止单点时间漂移导致误判
密钥自动更新策略：什么时候该换？
“过期失效”不等于“必须立刻作废”，很多场景需要平滑轮转。常见触发时机：
- token 被使用时，若剩余有效期 Refresh-Token 响应头
- 用户修改密码后，立即清空该用户所有未过期的 token（删数据库记录或 Redis key），而不是等它自然过期
- 密钥本身（如 HMAC secret）原则上不应频繁轮换；若需更新，采用双密钥机制：新旧密钥并存 24 小时，验证时先试新密钥，失败再试旧密钥，之后逐步下线旧密钥
硬编码密钥轮换时间（比如“每 7 天换一次”）不如按使用强度或安全事件驱动更可控。
容易忽略的边界问题：时区、精度、重放攻击
看似简单的过期判断，实际藏着几个高频翻车点：
-
time()返回的是系统本地时间戳，但 PHP 的date_default_timezone_set()不影响它 —— 所以只要服务器时钟准，就没问题；但如果你用new DateTime()算时间差，就必须统一时区（推荐始终设为UTC） - JWT 规范允许设置
nbf（not before）和iat（issued at），它们和exp一起构成完整时效窗口，漏判nbf会导致“还没生效就被接受” - 单纯过期检测不能防重放：攻击者截获一个未过期的 token，可重复使用。必须配合
jti（唯一 ID）+ 短期 Redis 黑名单，或一次性nonce参数
过期逻辑越前置（比如 Nginx Lua 层做基础 exp 检查），后续 PHP 处理就越轻量；但业务级时效规则（如“会员到期即停服务”）仍得在 PHP 里结合数据库状态做最终裁定。
