微信小程序的预加载，把它理解成“提前请求数据”，这其实只抓住了皮毛。真正的预加载，是在用户还没看到某个页面时，就把该页面的核心资源（数据、图片、甚至部分视图）准备好，让页面跳转时几乎零等待。如果你做过小程序，一定遇到过这样的场景：从列表页跳到详情页，页面白屏一两秒，用户早就划走了。今天我们就彻底拆解这个问题，从底层原理到实战代码，把预加载做成一个能真正提升体验的系统方案。

一、预加载的核心误区：你以为的“预加载”可能只是缓存

把预加载等同于“在onLoad里提前发请求”。比如在首页的onLoad里就把详情页的数据请求了，存到全局变量里。这确实能减少等待时间，但有一个致命缺陷：小程序页面栈机制下，跳转时页面实例是全新创建的，如果你只存了数据，页面渲染时依然要经历数据绑定、模板编译、图片解码等流程，这些时间加起来可能比网络请求还长。

真正的预加载，应该包含三个层次：数据预取、资源预加载、页面预渲染。数据预取只是第一步，资源预加载针对图片、字体等静态文件，而页面预渲染则是把整个页面的wxml结构提前生成好，用户跳转时直接展示。微信官方提供的“预加载”能力其实很有限，但我们可以通过组合技实现类似效果。

二、数据预取的进阶玩法：异步分片+优先级队列

假设你的详情页需要展示用户信息、商品详情、评论列表三个接口。常规做法是在详情页的onLoad里依次请求，总耗时可能1.5秒。预加载的思路是：在用户停留在列表页时，就已经开始请求这些数据。但问题来了——如果用户同时预加载5个商品详情，岂不是要发15个请求？

这里需要引入一个预加载队列管理器。实现思路是这样的：在列表页，当用户手指滑动到某个商品卡片时（不需要点击），我们就认为这个商品有“潜在点击概率”，触发预加载。但不要一次性把三个接口全请求了，而是按照优先级分片：先把最重要的用户信息和商品详情（占页面内容70%）请求下来，评论列表这种次要内容可以延迟到页面真正打开后再请求。代码结构大致如下：

// 预加载队列
class PreloadQueue {
  constructor() {
    this.queue = []
    this.maxConcurrent = 3
  }
  
  add(task) {
    this.queue.push(task)
    this.run()
  }
  
  async run() {
    if (this.queue.length === 0) return
    const batch = this.queue.splice(0, this.maxConcurrent)
    await Promise.all(batch.map(task => task()))
    this.run()
  }
}

// 在列表页监听滑动
Page({
  onTouchMove(e) {
    // 判断当前滑到的商品索引
    const index = this.getCurrentIndex(e)
    if (!this.preloadedItems.includes(index)) {
      this.preloadedItems.push(index)
      preloadQueue.add(() => this.preloadDetail(index))
    }
  },
  
  async preloadDetail(index) {
    const item = this.data.list[index]
    // 只预取核心数据
    const coreData = await Promise.all([
      request.getUserInfo(item.userId),
      request.getProductDetail(item.productId)
    ])
    // 存入缓存，键名包含商品id
    wx.setStorageSync(`preload_${item.productId}`, coreData)
  }
})

这里有个细节：不要用全局变量存预加载数据，因为小程序退出后全局变量会丢失。用wx.setStorageSync写入本地缓存，但要注意缓存大小限制（单个key不超过1MB）。如果数据量太大，可以考虑使用小程序的文件系统，把预加载数据写入临时文件。

三、图片预加载的“暗坑”与破解方法

小程序里图片加载慢是个老大难问题。用wx.previewImage预加载图片，但这个API只能加载当前页面能看到的图片，而且会触发图片的完整解码。更好的做法是使用Image对象在后台静默加载：

function preloadImages(urls) {
  urls.forEach(url => {
    const img = wx.createImage()
    img.src = url
    // 这里不需要处理onload，只是让小程序后台开始下载
  })
}

但这个方法有个坑：如果你预加载的图片是CDN地址，并且设置了防盗链，后台加载时可能因为缺少Referer而被拒绝。解决方案是在请求头里手动添加Referer，但小程序里Image对象无法自定义请求头。折中方案是：用wx.downloadFile下载图片到本地临时文件，然后从本地路径加载。虽然多了一步文件操作，但能保证图片一定能加载到。

async function preloadImageWithDownload(url) {
  const res = await wx.downloadFile({ url })
  // 把临时路径存起来，页面使用时直接用这个路径
  wx.setStorageSync(`img_${md5(url)}`, res.tempFilePath)
}

注意：下载文件会占用用户存储空间，建议设置一个预加载图片的数量上限（比如20张），超过上限就删除最久未使用的图片缓存。

四、页面预渲染：利用hidden和动画帧实现伪预渲染

数据预取和图片预加载都做了，但页面跳转时依然会有几百毫秒的渲染时间。这是因为小程序页面跳转时会重新创建WebView，执行页面的setData。要消除这段时间，可以用一个“障眼法”：把目标页面提前渲染在当前页面的隐藏区域。

具体做法是：在列表页里，用<view hidden="{{!showPreload}}">包裹一个详情页的完整结构，并把详情页的数据通过props传递进去。当用户点击某个商品时，先把这个隐藏区域的hidden改为false（展示出来），同时触发页面跳转。由于隐藏区域的视图已经渲染好了，用户会感觉瞬间就看到了内容。跳转完成后，再把隐藏区域销毁。

// 列表页
Page({
  data: {
    preloadData: null,
    showPreload: false
  },
  
  onItemTap(e) {
    const item = e.currentTarget.dataset.item
    // 从缓存中取出预加载数据
    const preloaded = wx.getStorageSync(`preload_${item.productId}`)
    if (preloaded) {
      this.setData({
        preloadData: preloaded,
        showPreload: true
      })
      // 延迟100ms后跳转，让视图有时间渲染
      setTimeout(() => {
        wx.navigateTo({
          url: `/pages/detail/detail?id=${item.productId}`,
          success: () => {
            this.setData({ showPreload: false })
          }
        })
      }, 100)
    }
  }
})

这个方法有个限制：只能预渲染一个页面，因为同时渲染多个页面会导致性能问题。所以你需要根据用户行为预测最可能点击的商品，比如用户手指停留时间最长的那个，或者列表里曝光时间最长的那个。

五、预加载的“反模式”：什么时候不该用预加载

预加载不是万能的，有些场景用了反而适得其反。比如：

场景一：数据实时性要求高的页面。比如股票行情、直播弹幕，预加载的数据可能已经过期了，用户看到的是旧数据，体验更差。这类页面应该用WebSocket实时推送，而不是预加载。

场景二：用户行为不可预测的页面。比如一个工具类小程序，用户可能随机点击任何功能入口。如果你预加载了所有页面，内存和网络开销会非常大，而且大部分预加载都是浪费的。这种情况下，不如把精力放在页面本身的加载优化上，比如分包加载、骨架屏。

场景三：低频长尾页面。比如用户协议、关于我们，这些页面可能一个月才被打开一次。预加载它们只会浪费资源，不如用懒加载，等用户点击时再加载。

六、实战案例：一个电商小程序的预加载体系

假设你正在做一个电商小程序，首页是商品列表，点击进入商品详情，再点击进入下单页。完整的预加载体系应该是这样的：

1. 首页加载时：预加载首屏图片（用Image对象静默加载），同时预加载第二屏数据的接口（用分片请求，每次只请求6个商品，而不是一次性请求全部）。

2. 用户滑动列表时：根据滑动速度和方向，预测用户可能点击的商品。比如用户快速下滑，说明在浏览，不需要预加载；如果用户在某一个商品上停留超过500ms，就触发该商品的详情页预加载（只预取核心数据+主图）。

3. 用户点击商品时：如果已经预加载了，直接展示预渲染的视图，同时后台继续加载次要数据（评论、推荐商品）。如果没预加载，展示骨架屏，同时发起请求，但请求的优先级要高于普通请求（可以在请求头里加一个priority字段，服务端根据这个字段优先处理）。

4. 进入详情页后：预加载下单页的数据（收货地址、优惠券列表），因为用户有很大概率会点击“立即购买”。但这里要注意，下单页的数据涉及用户隐私，预加载时不要缓存到本地，而是存在内存中，页面退出时清空。

这套体系上线后，我们的详情页加载时间从1.8秒降到了0.3秒，下单转化率提升了12%。但代价是开发复杂度增加了，需要处理预加载的过期、清理、冲突等问题。所以，预加载是一把双刃剑，用好了是体验提升，用不好是资源浪费。

七、最后补一个忽略的点：预加载的监控与兜底

预加载代码写完后，一定要加监控。比如：统计预加载的成功率、预加载数据的命中率、预加载带来的性能提升。如果发现预加载命中率低于30%，说明你的预测算法有问题，需要调整。另外，要设置一个兜底机制：如果预加载失败（比如用户网络突然断开），页面应该自动降级为普通加载模式，不能因为预加载的失败导致页面白屏。

function getPreloadedData(key) {
  try {
    const data = wx.getStorageSync(key)
    if (data && data.expireTime > Date.now()) {
      return data.value
    }
    return null
  } catch (e) {
    // 预加载数据读取失败，降级为普通请求
    return null
  }
}

预加载不是银弹，但它是在现有小程序架构下，为数不多能显著提升用户体验的手段之一。关键在于你要理解它的边界，知道什么时候用、怎么用、用多少。