Taro Vue3 微信小程序线稿库首页工程化复盘：分页、分类缓存与回到顶部

· 5 min read · 前端工程 AR绘图桌 Taro 微信小程序 性能优化

做 AR 绘图桌这款 Taro 4 + Vue 3 微信小程序，核心场景是让用户在小程序里浏览线稿素材、自己上色。首页线稿库是打开频次最高的页面，但早期版本有几个体验硬伤：列表一拉到底就空、切分类要干等加载、滚到几十屏想回顶却找不到入口。这一轮我把这些集中解决掉，顺便把两个编译告警也清了。下面是完整的工程复盘。

问题背景

线稿库按分类浏览，数据走分页接口。初期实现有三个体验缺陷，加两个编译期告警：

  • 列表触底后没有续加载，用户拉到底就空；
  • 切换分类时重复请求第一页，加载顿挫；
  • 长列表缺少回到顶部入口，滚深了回不去；
  • app.json 报 无效的 window['glassEaselWebview']；
  • Skyline 渲染下 wxss 大量 -webkit-/-ms- 前缀告警。

分页与触底加载

基于 scroll-view 实现，每页 20 条，用 lower-threshold: 150 提前一屏半触发，避免滚到底才看到 loading：

<scroll-view
  scroll-y
  :scroll-into-view="scrollIntoView"
  :lower-threshold="150"
  @scrolltolower="loadMore"
  @scroll="onScroll"
/>

loadMore 必须有两个闸门——加载中和无更多——否则快速滑动会并发打爆接口：

async function loadMore() {
  const c = caches[activeCat.value]
  if (c.loading || !c.hasMore) return
  c.loading = true
  const res = await fetchLinearts(activeCat.value, c.page)
  c.list.push(...res.items)
  c.page += 1
  c.hasMore = res.hasMore
  c.loading = false
}

分类内存缓存

用 reactive 对象按分类缓存已加载数据，命中直接切、零请求：

const caches = reactive({})  // key: 分类名 -> { list, page, hasMore, loading }

function switchCat(cat) {
  if (caches[cat]) {           // 命中缓存：零请求
    activeCat.value = cat
    scrollToTop()
    return
  }
  caches[cat] = { list: [], page: 1, hasMore: true, loading: false }
  activeCat.value = cat
  loadFirstPage(cat)
}

切分类时还要 scrollToTop，否则会停在新列表的中部，看着很怪。

回到顶部的两段式技巧

滚动超过 400px 时浮出回顶按钮，由 scroll-view @scroll 监听距离控制显隐。直接 scroll-into-view 同一个锚点 id，第二次不生效——因为 id 没变，DOM 不重新计算。改成两段式：

function backToTop() {
  scrollIntoView.value = ''                       // 先清空
  nextTick(() => { scrollIntoView.value = 'page-top' })  // 再置锚点
}

锚点 id="page-top" 放在 hero 区域，scroll-view 开 scroll-with-animation 平滑回顶。

强制刷新时机

useDidShow 切前台不能每次都重拉。只在"上一页是素材管理页"或"当前分类无缓存"时拉第一页，否则读内存缓存。用 Taro.getCurrentPages() 拿倒数第二个路由判断来源：

useDidShow(() => {
  const pages = Taro.getCurrentPages()
  const prev = pages[pages.length - 2]?.route
  if (prev === 'pages/admin/index' || !caches[activeCat.value]) {
    loadFirstPage(activeCat.value)
  }
})

缓存是会话级的，小程序重启失效——对这个场景够用，不值得上持久化。

编译告警治理

告警一：app.json 报 无效的 window['glassEaselWebview']。查 glass-easel 迁移文档确认，glassEaselWebview 是 app.json 顶层字段，与 pages / window 平级，不是 window 子项。移出 window 至顶层即解决。

告警二：Skyline 下 wxss -webkit-/-ms- 前缀告警。源码无前缀，是 Taro 默认开启的 autoprefixer 按 browserslist 注入，而 Skyline 只认标准属性。在 config/index.js 显式关闭 mini 端 autoprefixer（h5 保留）：

// config/index.js
mini: {
  postcss: {
    autoprefixer: { enable: false }
  }
}

改完必须重启 npm run dev:weapp 才生效。注意：Taro 的 mini.postcss 不写 autoprefixer 不等于关闭，默认仍开启，必须显式 enable: false。

方法论沉淀

这一轮改动没有高深算法，但全是前端该有的工程判断力。前端列表页的体验问题，本质是状态与请求的管理：缓存策略决定重复请求是否被消灭，回顶交互决定长列表是否可用，编译告警是渲染底座演进的显式信号而非噪音。Skyline、glass-easel 都在替换旧 WebView，字段层级与样式规范持续变化，把告警当噪音忽略，等于放弃一次理解底座演进的机会。

这类细节堆叠起来，就是产品顺不顺手的分界，也是面试里能讲清楚"你到底解决了什么问题"的硬证据。更多工程复盘见 blog.alleria.cn。