Yew 应用性能优化应该从哪些地方入手？

Yew 的性能优化不要一上来就盯着 WebAssembly。很多 Yew 应用变慢，不是 Rust 算不动，而是组件重复渲染、状态放得太高、列表没有 key、Wasm 包太大、JS 和 Wasm 之间传了太多数据。先用浏览器 Performance 面板和日志确认瓶颈，再决定优化手段，通常比凭感觉改代码有效得多。

一个实用顺序是：先减少不必要渲染，再优化列表和状态，再看包体积，最后处理 JS/Wasm 边界和网络请求。过早优化会让组件变复杂，尤其是到处加 memo、callback 和手写比较逻辑，后面维护成本会很高。

Yew 性能问题通常出在哪里？

组件渲染是最常见的入口。父组件状态变化时，子组件可能跟着重新计算和重新生成虚拟 DOM。如果 props 很大，或者列表项很多，这个成本会被放大。函数组件里可以用 use_memo 缓存昂贵计算，用 use_callback 稳定回调引用，但前提是你真的遇到了重复计算。

rust
#[function_component(TotalPrice)]
fn total_price(props: &CartProps) -> Html {
    let total = use_memo(props.items.clone(), |items| {
        items.iter().map(|i| i.price * i.count).sum::<u32>()
    });

    html! { <span>{ format!("total: {}", *total) }</span> }
}

列表渲染要特别注意 key。没有稳定 key 时，列表插入、删除和重排会让框架更难复用已有节点。key 不要用数组下标，尤其是可排序、可删除列表，否则 UI 状态可能错位。

rust
html! {
  <ul>
    { for props.items.iter().map(|item| html! {
      <li key={item.id}>{ &item.title }</li>
    }) }
  </ul>
}

Yew 性能优化最怕“看起来高级”。稳定 key、合理状态位置、少传大 props、控制包体积，这些基础动作往往比复杂技巧更有效。先定位，再优化，最后用指标确认收益，才不会把代码越改越难维护。

追问

use_memo 和 use_callback 是不是应该到处加？

不应该。它们本身也有依赖比较和额外心智成本，只有计算确实昂贵、回调引用确实导致子组件重复渲染时才值得加。简单字符串拼接、很小的列表过滤，直接计算通常更清楚。踩坑点是依赖写错：少写依赖会拿到旧值，多写依赖又等于每次重建。优化前最好先用日志或 Performance 面板确认问题存在。

类组件里的 should_render 该怎么用？

should_render 适合状态变化频繁但视图不一定需要更新的类组件。比如内部计数、节流状态、缓存字段变化时，可以返回 false 避免重绘。取舍是逻辑会更绕，状态和视图之间的关系必须非常清楚。常见坑是忘记某个字段会影响 UI，结果页面不刷新，看起来像状态丢了。

大列表在 Yew 里怎么优化？

先加稳定 key，再考虑分页、搜索节流和虚拟滚动。几百条以内通常不用急着上虚拟列表，代码复杂度不一定划算；上千条并且每项结构复杂时，虚拟滚动才明显。边界是可访问性和交互细节，虚拟滚动可能影响浏览器查找、焦点管理和滚动恢复。真实项目里要同时测首屏时间、滚动流畅度和用户操作是否丢状态。

Wasm 包体积应该怎么压？

发布构建至少要开启 release 优化、LTO、strip，并检查是否引入了过重依赖。opt-level = "z" 偏向包体积，opt-level = 3 偏向运行速度，具体选哪个要看应用瓶颈。踩坑点是为了省几十 KB 牺牲了热路径性能，或者引入一个 crate 只用一个小函数却带来大量依赖。可以用 twiggy 或构建报告看体积来源，而不是盲删。

toml
[profile.release]
opt-level = "z"
lto = true
codegen-units = 1
panic = "abort"
strip = true

JS 和 Wasm 交互会成为瓶颈吗？

会，尤其是频繁传大对象、数组或字符串时。Wasm 计算快不代表跨边界调用免费，序列化、拷贝和绑定层都会消耗时间。优化思路是减少调用次数，批量传输数据，或者把连续计算留在同一侧完成。边界是不要为了减少跨边界调用把所有逻辑都塞进 Wasm，因为 DOM 操作和浏览器 API 仍然天然在 JS/浏览器侧更合适。