JWT 认证中空 Cookie 导致 Fetch 请求挂起的解决方案
在 JWT 身份验证流程中，若后端接口未能从请求中获取到有效的 Cookie 令牌，且未主动返回明确的 HTTP 响应，Express 框架将保持连接等待，从而导致前端发起的 Fetch 请求持续处于 pending 状态。解决此问题的核心在于：当检测到 token 缺失时，中间件必须立即返回 401 状态码以终止请求。
许多前端开发者在实际项目中都曾遭遇过类似的困扰：一个基础的 Fetch API 调用，在浏览器网络面板中却长时间显示为“pending”状态，页面交互也随之停滞。经过深入排查，问题的根源通常指向后端服务，更具体地说，是 JWT 身份验证中间件中存在的一个逻辑缺陷。
在采用 Cookie 存储 JWT 的认证体系里，isAuthenticated 中间件的职责非常清晰：验证请求是否附带了有效的令牌，并给出明确的认证结果。然而，一个常见的编码疏忽是：未能妥善处理 req.cookies.token 值为空（undefined 或空字符串）的场景。在这种情况下，jwt.verify() 函数根本不会被执行，其异步回调函数也永远不会被触发，导致 Express 的响应对象（res）始终未被终结。其直接后果是 HTTP 连接持续挂起，前端的 Fetch 请求陷入无限等待，最终表现为令人费解的“pending”状态。
解决方案非常明确：在尝试调用 jwt.verify() 进行令牌验证之前，必须先行检查 token 是否存在且格式有效。一旦发现令牌缺失，应立即返回一个结构化的错误响应，主动关闭 HTTP 连接。
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）适用于令牌存在但无效（如已过期、签名错误）
return res.status(403).json({
ok: false,
message: 'Invalid or expired token.'
});
}
// ✅ 令牌验证成功，返回用户信息
res.status(200).json({ ok: true, user });
});
};
当然，修复核心逻辑漏洞只是构建健壮认证系统的第一步。为了确保整个身份验证链路的可靠性，以下几个最佳实践同样至关重要：
- 精确使用 HTTP 状态码：401 Unauthorized 表示“未提供身份凭证”，适用于认证缺失；403 Forbidden 表示“凭证无效或权限不足”，适用于认证失败。两者语义不同，应准确区分使用；
- 保持 Cookie 安全配置一致：在用户退出登录（logout）的路由中，清除 Cookie 所使用的安全选项（如 secure, sameSite, httpOnly）必须与登录时设置的选项完全匹配。配置不一致可能导致 Cookie 清除操作失败；
- 前端实现请求超时与容错：为 Fetch 请求配置合理的超时机制（例如使用 AbortSignal.timeout(8000)），可以有效避免因服务端偶发性无响应而导致的前端界面长时间阻塞；
- 严格校验环境变量：在部署前，务必确认
process.env.SECRET等关键环境变量已正确加载。若密钥缺失，jwt.verify()可能抛出同步异常，需结合 Express 的全局错误处理中间件进行捕获和管理。
综上所述，通过实施上述优化措施，我们不仅能彻底解决因空 Cookie 引发的请求挂起难题，更能系统性地提升 JWT 认证机制的稳定性与可维护性。在软件开发中，细节决定成败，而严谨的代码逻辑正是保障优质用户体验的坚实基础。
