处理 Node.js jsonwebtoken 报错的核心方案是捕获 TokenExpiredError 异常并通过 Refresh Token 接口换取新 Access Token，不要直接延长已过期令牌。

快速处理思路

后端中间件捕获验证错误，区分过期错误与其他签名错误，返回特定状态码供前端识别。

jwt.verify(token, secret, (err, decoded) => {  if (err) {    if (err.name === 'TokenExpiredError') {      return res.status(401).json({ error: 'TOKEN_EXPIRED' });    }    return res.status(403).json({ error: 'INVALID_TOKEN' });  }  next();});

前端拦截器检测到 TOKEN_EXPIRED 错误时，调用刷新接口获取新令牌，重试原请求。

为什么会这样

Access Token 设置短有效期是为了降低令牌泄露后的风险窗口，刷新令牌机制用于在不重新输入密码的情况下恢复会话。

jsonwebtoken 库在 verify 阶段检查 exp claim，当前时间超过 exp 值即抛出 TokenExpiredError。部分上层框架可能将此错误重命名为 JWTExpiredError，但底层逻辑一致。直接修改过期时间会破坏签名验证，必须重新签发。

分步处理

第一步在后端创建刷新令牌接口，验证刷新令牌有效性后签发新 Access Token。

app.post('/refresh', (req, res) => {  const { refreshToken } = req.body;  jwt.verify(refreshToken, refreshSecret, (err, user) => {    if (err) return res.sendStatus(403);    const newAccessToken = generateAccessToken(user);    res.json({ accessToken: newAccessToken });  });});

第二步在前端请求拦截器中监听 401 响应，触发刷新逻辑并锁定并发请求防止重复刷新。

第三步在刷新成功后将新 Access Token 写入存储，重试队列中失败的请求，刷新令牌失效则跳转登录页。

怎么验证是否生效

查看后端日志确认刷新接口被调用且 verify 成功，新令牌 exp 时间应晚于当前时间。

前端 Network 面板观察原失败请求状态码变为 200，Authorization 头携带新令牌。使用 jwt.io 解码新令牌，确认 exp 字段已更新且 sub 用户信息一致。

常见坑

刷新令牌存储在 localStorage 易受 XSS 攻击，建议存入 HttpOnly Cookie 并设置 Secure 标志。

未实现刷新令牌轮换或撤销机制，导致旧刷新令牌泄露后可长期滥用。建议在每次刷新时使旧刷新令牌失效并签发新刷新令牌。

前端未处理刷新失败场景，导致无限重试请求造成服务器压力。刷新接口返回 403 时应强制清除本地令牌并跳转登录。

常见问题

JWTExpiredError 和 TokenExpiredError 有什么区别？

TokenExpiredError 是 jsonwebtoken 库原生错误名，JWTExpiredError 通常是框架封装后的别名，捕获时需兼容两种名称。

刷新令牌有效期设置多久合适？

公开资料中没有看到可靠的量化数据，通常建议比 Access Token 长得多，如 7 天至 30 天，具体取决于业务安全等级。

Access Token 过期了能直接修改 exp 吗？

不能，令牌签名包含 payload 内容，修改 exp 会导致签名验证失败，必须使用密钥重新签发新令牌。

参考来源

• GitHub - auth0/node-jsonwebtoken: https://github.com/auth0/node-jsonwebtoken
• npm - jsonwebtoken: https://www.npmjs.com/package/jsonwebtoken
• OWASP - JSON Web Token Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html