性能与体验优化

性能优化最怕两件事：

• 一上来就做复杂优化，但没抓到主要瓶颈
• 页面明显卡顿了，却不知道该从包体、渲染还是数据更新下手

这章只讲最值得优先做的内容。

优先级最高的 4 个方向

1. 先控制首屏包体

如果首屏就很重，后面很多体验问题都会被放大。

优先看：

• 是否应该分包
• 是否引入了过重依赖
• 图片和静态资源是否过大

2. 再控制列表渲染压力

很多页面卡顿，本质不是“框架慢”，而是：

• 一次渲染的数据太多
• 模板表达式太重
• 每次更新都替换整个大数组

3. 再关注状态更新粒度

在 wevu 语境里，这一点尤其重要。 如果你的状态设计足够清晰，更新路径就更容易收敛。

4. 最后才是细节微调

例如：

• 动画节奏
• 节流防抖
• 占位骨架屏

一个典型的大列表例子

不太推荐的写法：

list.value = response.bigList

如果 bigList 很大，而且更新频繁，页面很容易有压力。

更稳的思路通常是：

list.value = [...list.value, ...nextPage]

并配合：

• 分页加载
• 下拉刷新重置
• 滚动到底部再加载更多

模板里尽量不要做复杂计算

比如这种写法，要慎用：

<text>
{{ goods.price * goods.count * discountMap[goods.type] }}
</text>

更推荐把复杂计算提前到脚本层：

function getItemTotal(item: CartItem) {
  return item.price * item.count * discountMap[item.type]
}

模板只负责展示：

<text>
{{ getItemTotal(goods) }}
</text>

wevu 里一条很重要的性能建议

把状态按“变化频率”和“消费范围”拆开。

例如：

const summary = ref({
  totalPrice: 0,
  totalCount: 0,
})

const list = ref<CartItem[]>([])
const loading = ref(false)

这种拆分通常会比把所有页面状态都塞进一个超级对象里更稳。

包体优化的最小动作

如果你刚开始做优化，优先做这些：

• 把低频业务页分包
• 检查大图和重复资源
• 避免为了一个小功能引入很重的依赖
• 尽量复用已有能力，不要叠加重复 SDK

体验优化不要只盯性能指标

用户真正感受到的“快”，很多时候来自这些设计：

• 加载时有明确反馈
• 首屏先展示骨架和核心信息
• 下拉刷新和分页行为稳定
• 错误提示可恢复

一份很实用的性能检查清单

[ ] 首屏业务已经做主包/分包区分
[ ] 大列表使用分页或渐进加载
[ ] 模板里没有明显复杂表达式
[ ] 大状态没有每次整块替换
[ ] 图片和静态资源做过体积检查

优化完性能以后，建议你继续看：

• 调试与排错（按层定位）
• 构建、预览与上传