通过封装一个统一的请求函数，在内部拦截响应并依据状态码或业务字段执行不同的处理逻辑，即可实现接口请求结果的网关策略。具体做法是定义一个包含默认配置和错误映射的 request 函数，利用 fetch 发起请求后，先检查 http 状态，再解析 json 数据，最后根据返回的 code 字段分发到成功、重试或终止分支。这样调用方只需关注业务数据，无需重复编写鉴权刷新或异常降级代码。
如何统一处理 HTTP 状态码与业务错误码
网关策略的核心在于区分网络层错误和应用层错误。HTTP 状态码如 401 或 500 代表传输或服务器层面的问题，而业务错误码如 -1 或 40001 代表具体的业务逻辑失败。在封装中，我们优先判断 HTTP 状态，若为 200 则进一步解析 JSON 并检查业务 code。对于 401 错误，策略通常是尝试刷新 Token 后重试；对于 5xx 错误，策略可能是记录日志并抛出通用异常；对于业务错误，则直接返回错误信息供 UI 展示。
const API_BASE = 'https://api.example.com';
// 模拟 Token 刷新机制
let isRefreshing = false;
let refreshSubscribers = [];
function onTokenRefreshed(callback) {
refreshSubscribers.push(callback);
}
function tokenRefreshed() {
refreshSubscribers.forEach(cb => cb());
refreshSubscribers = [];
}
async function refreshToken() {
// 实际场景中这里会调用 /auth/refresh 接口
console.log('Refreshing token...');
return 'new_access_token';
}
async function request(url, options = {}) {
const defaultHeaders = {
'Content-Type': 'application/json',
'Authorization': `Bearer ${localStorage.getItem('token')}`
};
try {
const response = await fetch(`${API_BASE}${url}`, {
...options,
headers: { ...defaultHeaders, ...options.headers }
});
// 1. 处理 HTTP 级别的状态码
if (!response.ok) {
if (response.status === 401 && !options._isRetry) {
// 2. 401 未授权，触发网关刷新策略
if (!isRefreshing) {
isRefreshing = true;
const newToken = await refreshToken();
localStorage.setItem('token', newToken);
isRefreshing = false;
tokenRefreshed();
} else {
// 等待刷新完成
await new Promise(resolve => {
onTokenRefreshed(() => resolve());
});
}
// 3. 重试原请求
return request(url, { ...options, _isRetry: true });
}
throw new Error(`HTTP Error: ${response.status}`);
}
const data = await response.json();
// 4. 处理业务级别的状态码
if (data.code !== 0) {
// 网关策略：根据 code 决定是提示用户还是静默失败
if (data.code === 40001) {
throw new Error('Session expired, please login again');
}
throw new Error(data.message || 'Business Error');
}
return data.data;
} catch (error) {
console.error('Request failed:', error);
throw error;
}
}
// 使用示例
request('/user/profile')
.then(profile => console.log('Profile:', profile))
.catch(err => console.error('Caught:', err.message));上述代码展示了完整的网关策略实现。首先定义了 request 函数，它接收 URL 和可选的配置对象。在请求发出后，代码首先检查 response.ok。如果状态码不是 200-299 之间，进入错误处理分支。特别地，当遇到 401 时，代码检查是否正在刷新 Token。如果没有，则设置标志位并调用 refreshToken，刷新成功后更新本地存储并通知等待的请求重试。如果正在刷新，当前请求会挂起直到刷新完成。对于非 401 的 HTTP 错误，直接抛出异常。如果 HTTP 状态正常，则解析 JSON 并检查 data.code。如果业务码不为 0，则根据具体码值抛出相应的业务异常。这种分层处理确保了网络问题和业务问题被正确区分和处理。
立即学习“Java免费学习笔记（深入）”；
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
如何实现请求拦截与结果缓存策略
除了错误处理，网关策略还常包括请求拦截和结果缓存。请求拦截可以在发送前修改请求头或参数，例如添加时间戳防止缓存或注入用户 ID。结果缓存则用于减少重复请求，特别是对于不常变化的静态数据。在封装中，我们可以维护一个简单的内存缓存 Map，以请求 URL 和参数为键，存储响应数据和过期时间。在发起请求前，先检查缓存是否有效。如果有效且未过期，直接返回缓存数据；否则发起请求，并将结果存入缓存。这种策略可以显著降低服务器负载并提升用户体验。
// 简单的内存缓存实现
const cacheMap = new Map();
const CACHE_DURATION = 5 * 60 * 1000; // 5分钟
async function cachedRequest(url, options = {}) {
const cacheKey = `${url}:${JSON.stringify(options.params || {})}`;
const now = Date.now();
// 1. 检查缓存
const cached = cacheMap.get(cacheKey);
if (cached && (now - cached.timestamp) < CACHE_DURATION) {
console.log('Cache hit for:', url);
return cached.data;
}
// 2. 发起请求
try {
const response = await fetch(`${API_BASE}${url}`, {
...options,
headers: { ...options.headers, 'Cache-Control': 'no-cache' }
});
if (!response.ok) {
throw new Error(`HTTP Error: ${response.status}`);
}
const data = await response.json();
if (data.code !== 0) {
throw new Error(data.message || 'Business Error');
}
// 3. 更新缓存
cacheMap.set(cacheKey, {
data: data.data,
timestamp: now
});
return data.data;
} catch (error) {
console.error('Cached request failed:', error);
throw error;
}
}
// 使用示例
cachedRequest('/config/settings', { params: { lang: 'zh' } })
.then(config => console.log('Config:', config));该代码段展示了如何在 request 基础上增加缓存策略。cachedRequest 函数首先构建唯一的缓存键，结合 URL 和查询参数。然后检查 cacheMap 中是否存在该键，并且验证时间戳是否在 CACHE_DURATION 内。如果命中缓存，直接返回数据并记录日志。如果未命中，则发起实际的 HTTP 请求。请求成功后，将响应数据和时间戳存入 cacheMap。这种实现简单有效，适用于大多数前端场景。需要注意的是，对于涉及用户敏感数据或频繁更新的接口，应谨慎使用缓存或设置更短的过期时间。此外，缓存键的构建必须确保唯一性，避免不同请求的数据混淆。
基于特定输入条件如何动态调整网关路由
在某些复杂场景下，网关策略需要根据请求的具体内容动态调整路由或处理方式。例如，根据用户等级、地区或设备类型，将请求分发到不同的后端服务或应用不同的限流策略。在封装中，我们可以在 request 函数中加入条件判断逻辑，根据传入的选项或全局状态修改目标 URL 或请求头。这种动态路由能力使得网关更加灵活，能够适应多租户、A/B 测试或灰度发布等需求。通过这种方式，开发者可以在不修改调用方代码的情况下，实现复杂的后端路由逻辑。
在实际应用中，动态路由通常依赖于全局配置或上下文信息。例如，我们可以定义一个 getRouteStrategy 函数，根据用户 ID 或其他属性计算目标服务地址。然后在 request 函数中调用该函数，动态替换 API_BASE。此外，还可以根据请求频率实施动态限流，如果检测到短时间内大量请求，自动切换到低优先级队列或返回降级数据。这种策略需要结合监控和告警系统，确保在异常情况下能够快速响应。通过这种方式，网关不仅是一个请求代理，更是一个智能的路由和决策中心。
