微信小程序如何利用Memoization缓存API请求结果来提升性能？

在微信小程序项目里，几乎每个页面都离不开wx.request。用户在几个页面之间来回跳转时，同一个接口往往会被反复调用：列表页进入详情页再返回，onShow里又刷新一次数据；Tab切换时多个页面各自请求同一份配置。这些重复请求不仅浪费流量和服务器资源，也让用户等待不必要的加载时间。Memoization（记忆化）是解决这类问题的经典思路——把已经请求过的结果缓存下来，下次需要同样数据时直接从缓存读取，跳过网络请求。这篇文章详细讲解如何在小程序中落地这套缓存方案。

一、Memoization的核心思想与小程序中的适用场景

Memoization的本质是“以空间换时间”：第一次执行一个耗时操作（这里是网络请求）时，把结果按某种键存储起来，后续遇到相同键的请求直接返回存储的结果。它和HTTP缓存、CDN缓存不同，Memoization发生在代码层面，由开发者完全控制命中策略，粒度可以精确到某个接口的某组参数。

在小程序中，以下场景特别适合使用请求缓存：第一，配置类数据，例如首页轮播图、分类目录、省市区列表，这类数据更新频率低但访问频繁；第二，用户会话数据，例如用户信息、会员权益，登录后短时间内基本不变；第三，页面返回时的列表恢复，从详情页返回列表页时，用缓存数据先渲染界面，再决定是否需要静默刷新。

反过来，订单状态、支付结果这类强实时性数据不适合盲目缓存，或者只能缓存极短时间。所以在动手之前，先给自己的接口分个类：哪些是“读多改少”的，哪些是必须实时的，这决定了后面的缓存策略设计。

二、基础实现：一个带过期时间的请求缓存模块

先从最简单的版本开始。我们在utils目录下新建一个cachedRequest.js，内部维护一个Map作为缓存容器，key由接口地址和参数共同生成，value包含数据和过期时间戳。

const cache = new Map();

// 生成缓存键：地址 + 排序后的参数
function buildKey(url, params) {
  const sorted = {};
  Object.keys(params || {}).sort().forEach(k => {
    sorted[k] = params[k];
  });
  return url + '?' + JSON.stringify(sorted);
}

function cachedRequest(url, params = {}, ttl = 60000) {
  const key = buildKey(url, params);
  const hit = cache.get(key);

  // 缓存命中且未过期，直接返回
  if (hit && Date.now() < hit.expireAt) {
    return Promise.resolve(hit.data);
  }

  // 未命中则真正发起请求
  return new Promise((resolve, reject) => {
    wx.request({
      url,
      data: params,
      success: res => {
        cache.set(key, {
          data: res.data,
          expireAt: Date.now() + ttl
        });
        resolve(res.data);
      },
      fail: reject
    });
  });
}

module.exports = { cachedRequest };

注意buildKey函数里对参数做了排序。这一点很关键：如果调用方传入的参数顺序不同，比如{a:1, b:2}和{b:2, a:1}，不排序的话会生成两个不同的key，导致本应命中的缓存失效。JSON.stringify对键的顺序敏感，排序后再序列化才能保证同样的参数集合得到同一个key。

ttl参数默认设置为60秒，实际使用时按数据特性调整。配置类接口可以给到5分钟甚至更长，而动态性较强的列表数据给10到30秒比较稳妥。调用方式很简单：

const { cachedRequest } = require('../../utils/cachedRequest');

Page({
  onShow() {
    // 60秒内重复调用不会真正发请求
    cachedRequest('https://api.ipipp.com/v1/categories', {}, 300000)
      .then(data => this.setData({ categories: data.list }));
  }
});

三、进阶：Promise去重，解决并发重复请求

基础版有一个明显漏洞：缓存只在请求完成后才生效。如果页面加载时三个组件同时请求同一个接口，三个请求几乎同时发出，谁都没命中缓存，等于白做了三次请求。解决办法是把“进行中的Promise”本身也存进缓存，后来的调用者拿到的是同一个Promise对象，等请求完成后大家共享同一份结果。

const cache = new Map();

function dedupRequest(url, params = {}, ttl = 60000) {
  const key = url + '?' + JSON.stringify(params);
  const hit = cache.get(key);

  // 已有结果且未过期
  if (hit && hit.expireAt && Date.now() < hit.expireAt) {
    return Promise.resolve(hit.data);
  }

  // 已有进行中的请求，直接复用同一个Promise
  if (hit && hit.pending) {
    return hit.pending;
  }

  const pending = new Promise((resolve, reject) => {
    wx.request({
      url,
      data: params,
      success: res => {
        cache.set(key, {
          data: res.data,
          expireAt: Date.now() + ttl,
          pending: null
        });
        resolve(res.data);
      },
      fail: err => {
        cache.delete(key); // 失败时清掉，允许重试
        reject(err);
      }
    });
  });

  cache.set(key, { pending, expireAt: 0 });
  return pending;
}

module.exports = { dedupRequest };

这个版本有两个细节值得留意。一是请求失败时要delete掉缓存条目，否则失败的Promise会被后续调用反复复用，用户就没有重试机会了。二是pending状态下expireAt设为0，避免被过期判断误判。经过这两层处理，无论是时间维度的重复请求还是并发维度的重复请求，都能被有效合并。

四、缓存失效与内存管理

缓存不能只进不出，否则小程序运行时间一长，内存占用会持续增长。尤其列表类接口参数包含分页和筛选条件，组合出来的key可能非常多。建议从三方面控制内存：

第一，限制缓存条目数量，超过上限时优先淘汰最久未访问的条目，也就是简化版的LRU策略。第二，在合适的时机主动清理，比如App的onHide时把过期数据清掉，只保留高频使用的配置缓存。第三，对列表数据不要按“参数组合”缓存全量结果，而是维护一份全局列表状态，翻页时增量追加。

const MAX_ENTRIES = 50;

function trimCache() {
  if (cache.size <= MAX_ENTRIES) return;
  // Map按插入顺序遍历，删掉最早的条目
  const overflow = cache.size - MAX_ENTRIES;
  let i = 0;
  for (const key of cache.keys()) {
    if (i++ >= overflow) break;
    cache.delete(key);
  }
}

另一个容易被忽视的问题是缓存失效的主动触发。当用户执行了写操作，比如编辑了昵称、修改了收货地址，相关的缓存必须立刻失效，否则界面展示的还是旧数据。可以给模块暴露一个invalidate方法：

function invalidate(urlPrefix) {
  for (const key of cache.keys()) {
    if (key.startsWith(urlPrefix)) {
      cache.delete(key);
    }
  }
}

// 修改资料成功后清掉用户信息相关缓存
invalidate('https://api.ipipp.com/v1/user');

五、返回列表页时的缓存渲染策略

小程序从详情页返回列表页时，onShow会再次触发。如果每次都重新请求并setData整个列表，用户会看到列表闪烁，滚动位置也可能丢失。更流畅的做法是：onShow时先用缓存数据立即渲染，再后台静默请求新数据，有差异时增量更新。

Page({
  data: { list: [], scrollTop: 0 },

  onShow() {
    // 第一步：缓存数据秒开界面
    const cached = wx.getStorageSync('goods-list-cache');
    if (cached && !this.data.list.length) {
      this.setData({ list: cached });
    }
    // 第二步：静默刷新
    this.fetchList(true);
  },

  fetchList(silent) {
    wx.request({
      url: 'https://api.ipipp.com/v1/goods',
      success: res => {
        const fresh = res.data.list;
        if (JSON.stringify(fresh) !== JSON.stringify(this.data.list)) {
          this.setData({ list: fresh });
          wx.setStorageSync('goods-list-cache', fresh);
        }
      }
    });
  }
});

这里把内存缓存和Storage结合了起来：内存Map在应用重启后会丢失，而Storage可以持久化，两者配合能在冷启动时也实现快速首屏。对比JSON字符串判断数据是否变化虽然不够优雅，但对于中小列表足够实用，可以避免不必要的setData触发页面重渲染。

总结

Memoization缓存看起来只是几行工具代码，但它对小程序体验的改善是实打实的：网络请求次数下降，页面切换更跟手，首屏时间明显缩短。落地时记住三个原则：按数据特性区分缓存时长，用Promise去重合并并发请求，建立主动失效机制保证数据一致性。把这套方案封装成统一的请求层，让业务代码无感接入，是性价比最高的实施方式。

微信小程序性能优化Memoization缓存修改时间：2026-09-07 23:56:38