JWT 认证中空 Cookie 导致 Fetch 请求挂起的解决方案

解决JWT认证中空Cookie导致Fetch请求挂起的问题

当JWT认证接口未收到有效Cookie时，若未显式返回响应，Express会持续等待，导致前端Fetch请求一直处于pending状态。解决方案是在token缺失时主动返回401响应。

许多开发者都遇到过这种情况：前端一个简单的Fetch请求，状态却一直显示为“pending”，页面响应似乎被卡住。经过排查，问题通常源于后端JWT认证中间件中存在一个容易被忽略的逻辑缺陷。

问题根源：未处理空Cookie情况

在基于JWT的Cookie认证流程中，isAuthenticated中间件的主要任务是验证请求是否携带了合法的令牌，并及时返回验证结果。但原始代码存在一个关键问题：它没有处理req.cookies.token为空值的情况。此时，jwt.verify()函数不会被调用，其回调函数也不会执行，而Express的响应对象始终没有结束。这导致HTTP连接一直保持打开状态，前端的Fetch请求只能无限期等待，最终表现为持续的“pending”状态。

解决方案：主动检查并返回响应

解决方法非常直接：在调用jwt.verify()之前，必须显式检查token是否存在且有效。一旦发现token缺失，应立即返回标准化的错误响应，主动关闭连接。

import jwt from "jsonwebtoken";
export const isAuthenticated = (req, res) => {
  const token = req.cookies.token;
  //  关键修复：token缺失时主动终止响应
  if (!token || typeof token !== 'string' || token.trim() === '') {
    return res.status(401).json({
      ok: false,
      message: 'Authentication token was not provided.'
    });
  }
  jwt.verify(token, process.env.SECRET, (err, user) => {
    if (err) {
      //  注意：403（Forbidden）适用于token存在但无效的情况
      return res.status(403).json({
        ok: false,
        message: 'Invalid or expired token.'
      });
    }
    //  token有效，返回用户信息
    res.status(200).json({ ok: true, user });
  });
};

完善认证系统的其他要点

修复核心漏洞只是第一步。要构建健壮的认证系统，还需要注意以下几个实践要点：

• 准确使用状态码：401 Unauthorized表示“未认证”，适用于缺少凭证的情况；403 Forbidden表示“已认证但无权限”，适用于凭证无效的情况。两者用途不同，不应混用。
• 保持Cookie安全配置一致：确保退出登录路由清除Cookie时使用的选项与登录时设置的选项完全一致。如果配置不匹配，可能导致Cookie清除失败。
• 前端实现容错处理：Fetch请求应设置超时机制，例如使用AbortSignal.timeout(8000)，避免因服务端响应遗漏导致前端界面长期阻塞。
• 校验环境变量：在上线前，务必确认process.env.SECRET已正确加载。否则，jwt.verify()可能抛出同步异常，需要配合Express的全局错误中间件进行处理。

通过以上改进，不仅可以彻底解决因空Cookie导致的请求挂起问题，还能全面提升整个认证系统的可靠性和可观测性。细节决定体验，而健壮的代码是良好用户体验的基础。