Next.js服务端渲染中Token生成与有效期管理方案咨询

针对Next.js SSR服务端调用API时的Token过期问题，结合你有Token生成API的前提，以下是几种分级最优方案：

1. 服务端本地内存缓存（单实例场景首选） #

直接在Node.js服务端用内存缓存存储Token和过期时间，实现简单且无额外依赖。

• 核心逻辑：每次调用业务API前，先检查缓存内的Token是否有效；无效则调用Token生成API获取新值并更新缓存
• 代码示例（用lru-cache自动处理过期）：

import LRU from 'lru-cache';

// 初始化缓存，设置过期时间比Token有效期短5分钟，提前触发刷新
const tokenCache = new LRU({
  max: 1,
  ttl: 55 * 60 * 1000
});

async function getValidToken() {
  let token = tokenCache.get('service_api_token');
  if (!token) {
    // 调用Token生成API，注意用服务端专属认证密钥（存环境变量）
    const tokenRes = await fetch('https://your-token-api.com/generate', {
      method: 'POST',
      headers: { 
        'Authorization': `Bearer ${process.env.SERVER_AUTH_SECRET}`
      }
    });
    const tokenData = await tokenRes.json();
    token = tokenData.access_token;
    tokenCache.set('service_api_token', token);
  }
  return token;
}

// 在SSR的getServerSideProps中使用
export async function getServerSideProps() {
  const validToken = await getValidToken();
  const apiRes = await fetch('https://your-business-api.com/data', {
    headers: { 'Authorization': `Bearer ${validToken}` }
  });
  const data = await apiRes.json();
  return { props: { data } };
}

• 优点：零额外部署成本，实现快速
• 缺点：多实例集群部署时，每个实例会维护独立Token，可能重复请求Token生成API；服务重启后缓存清空需重新获取

2. 分布式共享缓存（多实例集群场景首选） #

用Redis这类分布式缓存存储Token，让所有服务端实例共享同一份有效Token。

• 核心逻辑：和内存缓存逻辑一致，只是将缓存介质替换为Redis，利用Redis的过期自动清理机制
• 代码示例（用ioredis）：

import Redis from 'ioredis';

const redisClient = new Redis(process.env.REDIS_CONN_URL);

async function getValidToken() {
  let token = await redisClient.get('service_api_token');
  if (!token) {
    const tokenRes = await fetch('https://your-token-api.com/generate', {
      method: 'POST',
      headers: { 
        'Authorization': `Bearer ${process.env.SERVER_AUTH_SECRET}`
      }
    });
    const tokenData = await tokenRes.json();
    token = tokenData.access_token;
    // 设置Redis缓存过期时间为55分钟
    await redisClient.set('service_api_token', token, 'EX', 55 * 60);
  }
  return token;
}

• 优点：多实例共享Token，避免重复请求；服务重启不影响缓存
• 缺点：需要额外部署Redis服务，增加运维成本

3. 后台定时刷新（高可用场景补充） #

在服务端启动定时任务，提前主动刷新Token，避免业务API调用时才发现Token过期的延迟。

• 核心逻辑：服务启动后立即获取一次Token，之后每隔55分钟自动调用Token生成API更新缓存
• 代码示例（用node-schedule）：

import schedule from 'node-schedule';
import LRU from 'lru-cache';

const tokenCache = new LRU({ max: 1 });

// 刷新Token的核心函数
async function refreshToken() {
  try {
    const tokenRes = await fetch('https://your-token-api.com/generate', {
      method: 'POST',
      headers: { 
        'Authorization': `Bearer ${process.env.SERVER_AUTH_SECRET}`
      }
    });
    const tokenData = await tokenRes.json();
    tokenCache.set('service_api_token', tokenData.access_token);
  } catch (err) {
    console.error('Token刷新失败:', err);
    // 可添加重试逻辑
  }
}

// 初始化刷新+定时任务
refreshToken();
// 每55分钟执行一次刷新
schedule.scheduleJob('*/55 * * * *', refreshToken);

// SSR中直接取用缓存Token
export async function getServerSideProps() {
  const validToken = tokenCache.get('service_api_token');
  const apiRes = await fetch('https://your-business-api.com/data', {
    headers: { 'Authorization': `Bearer ${validToken}` }
  });
  const data = await apiRes.json();
  return { props: { data } };
}

• 优点：业务代码无需处理Token校验逻辑，简化流程；避免请求延迟
• 缺点：多实例部署时需避免重复执行定时任务；需添加异常处理防止Token刷新失败导致业务中断

关键注意事项 #

• Token生成API必须使用服务端专属的认证密钥（存储在环境变量中），绝对不能暴露给前端
• 所有Token相关逻辑必须在服务端完成，禁止前端参与Token生成或存储
• 需添加异常捕获机制，处理Token生成API调用失败的情况，避免影响业务流程

内容的提问来源于stack exchange，提问作者Elias