基于ExpressJS的Firebase Function如何处理第三方API刷新令牌

方案对比结论 #

优先选你提到的方案2，方案1在生产环境完全不推荐，具体原因如下：

• 无意义的性能损耗：方案1每次运费查询都要额外发一次token请求，把原本1次第三方接口调用变成2次，平白增加几十到上百毫秒的接口响应时间，用户看到运费报价的等待时间会明显变长。
• 易触发第三方限流：哪怕你日均访客只有二十多，遇到购物车页面重复刷新、多个用户同时结账的场景，短时间内发起大量token请求很容易触发第三方API的频控规则，轻则请求被拒，重则接口被临时封禁，直接影响结账流程。
• 额外成本浪费：Firebase Functions按运行时长、调用次数计费，多一次无效的第三方HTTP请求就会产生不必要的开销，哪怕金额不高也完全属于可以避免的浪费。

方案2的优化落地细节 #

方案2的核心逻辑（缓存token+过期校验）是行业通用的标准做法，但直接裸写校验逻辑容易踩坑，需要补几个关键处理：

• 预留过期缓冲窗口：不要卡着token的标称过期时间才刷新，建议提前1分钟判定为过期——比如15分钟（900秒）有效期的token，存的时候把过期判定阈值设为840秒，规避网络延迟、双方服务时钟不一致导致的“拿刚过期的token请求被拒”问题。
• 加并发锁防缓存击穿：如果token过期的瞬间同时进来3-5个运费查询请求，不要让所有请求都去触发token刷新。可以直接用Firebase Realtime Database的事务、或者Firestore的分布式锁机制，保证同一时间只有1个请求执行token刷新操作，其余请求等新token写入数据库后直接读取使用即可，避免无效的重复token请求。
• 加鉴权失败兜底逻辑：如果用缓存的token请求第三方接口返回401鉴权错误，不管存储的过期时间有没有到，直接清空缓存的旧token，强制刷新一次新token后重试业务请求，避免第三方主动吊销token、缓存值异常等边缘情况导致接口全量报错。

参考实现代码（Express + Firebase Functions） #

const admin = require('firebase-admin');
const db = admin.database();
const TOKEN_PATH = 'config/logisticsAccessToken';

async function getValidLogisticsToken() {
  const tokenRef = db.ref(TOKEN_PATH);
  // 用数据库事务实现天然的并发控制
  const tokenSnap = await tokenRef.transaction(currentCache => {
    const now = Date.now();
    // 缓存有效（留1分钟缓冲）直接返回
    if (currentCache?.value && currentCache.expireAt > now + 60 * 1000) {
      return currentCache;
    }
    // 缓存失效，调用第三方接口刷新token
    const tokenRes = await fetch('第三方物流鉴权接口', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        grant_type: 'refresh_token',
        refresh_token: '你持有的固定refresh_token'
      })
    });
    if (!tokenRes.ok) throw new Error('token刷新失败');
    const tokenData = await tokenRes.json();
    return {
      value: tokenData.access_token,
      // 优先用第三方返回的有效期，没有则按15分钟计算
      expireAt: now + (tokenData.expires_in || 15 * 60) * 1000
    };
  });
  return tokenSnap.snapshot.val().value;
}

// 运费查询接口逻辑
app.post('/api/shipping-rate', async (req, res) => {
  try {
    const accessToken = await getValidLogisticsToken();
    // 携带token请求运费查询接口
    const rateRes = await fetch('第三方物流运费查询接口', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${accessToken}`
      },
      body: JSON.stringify({
        items: req.body.items,
        address: req.body.address
      })
    });
    if (!rateRes.ok) throw new Error('运费查询失败');
    const rateData = await rateRes.json();
    return res.send(rateData);
  } catch (err) {
    // 遇到鉴权错误，清空缓存重试一次
    if (err.status === 401) {
      await db.ref(TOKEN_PATH).remove();
      // 此处可加重试逻辑，注意控制重试次数避免死循环
    }
    return res.status(500).send({ error: '运费查询暂时不可用' });
  }
});

补充说明：所有服务端对接短有效期access token的场景，不管业务请求量大小，「缓存token+提前过期校验+并发控制+错误兜底」都是通用的标准实践，没有生产环境会采用每次请求都刷新token的方案。

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