Yew 和 WebAssembly 集成时性能瓶颈通常在哪里？

Yew 应用最终运行在 WebAssembly 里，但性能不一定天然比 JavaScript 快。Wasm 擅长密集计算、类型明确的逻辑和可复用 Rust 代码；页面更新、DOM 操作、网络请求仍然要经过浏览器 Web API。也就是说，Yew 的性能优化重点不是“把一切改成 Rust”，而是减少无意义渲染、控制 Wasm 与 JS 的边界调用，并把大计算放到合适的位置。

集成链路先保持简单

新项目通常用 Trunk 最省心，Cargo.toml 配好 yew、wasm-bindgen、web-sys，HTML 里留一个挂载点即可。wasm-bindgen 负责把 Rust 类型和 JS 世界接起来，web-sys 提供浏览器 API 绑定。踩坑点是 web-sys 默认不开所有 feature，用到 Window、Storage、HtmlInputElement 之类类型时，要在依赖里显式声明。

toml
[dependencies]
yew = { version = "0.21", features = ["csr"] }
wasm-bindgen = "0.2"
gloo-net = "0.5"
web-sys = { version = "0.3", features = ["Window", "Storage"] }

rust
use yew::prelude::*;

#[function_component(App)]
fn app() -> Html {
    html! { <main>{ "Hello from Yew + Wasm" }</main> }
}

fn main() {
    yew::Renderer::<App>::new().render();
}

Wasm 与 JS 互操作要少而清楚

Rust 调 JS、JS 调 Rust 都可以，但边界不是免费的。字符串、JSON、大数组在两边来回传，会产生序列化和拷贝成本。小数据无所谓，图像像素、表格数据、日志流这类大块数据就要谨慎。更好的做法是让一边完成尽可能完整的一段工作，只把最终结果或必要索引传给另一边。

rust
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(js_namespace = console)]
    fn log(s: &str);
}

#[wasm_bindgen]
pub fn score(values: Vec<f64>) -> f64 {
    let sum: f64 = values.iter().sum();
    log("score calculated in wasm");
    sum / values.len() as f64
}

包体和渲染同样重要

很多 Yew 页面慢，不是 Rust 算得慢，而是首包大、依赖重、组件频繁重渲染。发布构建要打开优化，并用 wasm-opt 或 Trunk 的 release 流程压缩。组件层面，props 要尽量保持 PartialEq 有意义，列表项加 key，昂贵计算用 memo 或提前整理。边界是不要为了省一次渲染把状态拆得过碎，状态太分散会让数据流更难查。

性能优化先量再改

Yew + Wasm 项目最怕凭感觉优化：看到页面卡就拆组件，看到包体大就删依赖，最后问题可能还在接口或图片资源上。更稳的做法是先看浏览器 Performance、Network 和构建产物大小，再决定改哪里。边界也很明确：首屏慢优先查包体和资源加载，交互卡优先查主线程长任务，数据量大才重点看 Wasm 与 JS 的传输成本。

如果团队没有现成监控，至少在关键交互前后打点记录耗时，不要只看开发机上的主观体感。生产环境的低端手机、慢网络和浏览器扩展都会放大问题，优化方案必须覆盖这些边界。 同时要注意，Wasm 不是独立运行时，它仍然和页面脚本共享浏览器主线程的很多限制。一次过大的同步计算会挡住渲染，一次过多的日志输出也会拖慢调试环境。优化时保留可回滚空间，比一次性改掉整条链路更安全。

追问

Yew + Wasm 一定比 React 快吗？

不一定，尤其是以表单、DOM 交互和网络请求为主的页面，瓶颈通常不在语言运行速度。Yew 的优势在 Rust 类型系统、共享业务逻辑和某些计算密集场景。取舍是：如果团队已经有 Rust 能力，Yew 很有吸引力；如果只是普通内容站，为了“更快”迁移到 Wasm 往往不划算。

什么时候应该把计算放进 Web Worker？

当计算会阻塞主线程，比如大文件解析、图像处理、复杂加密或上万行数据聚合，就该考虑 Worker。Yew 组件本身负责 UI，长任务放主线程会让点击、输入和动画都卡住。踩坑点是 Worker 通信也要序列化数据，任务很小却丢给 Worker，反而会因为来回传输更慢。

wasm-bindgen 传 Vec 和传 JSON 有什么区别？

Vec<f64> 这类简单数值数组更适合跨边界传递，结构清楚，解析成本低。JSON 灵活，但每次都要序列化和反序列化，大对象会明显拖慢。边界做法是外部接口可以用 JSON 保持兼容，内部高频调用尽量改成明确类型或索引引用。

包体太大通常从哪里查？

先看依赖，不要把只用一个小功能的庞大 crate 拉进浏览器。再看 web-sys feature、调试符号、panic 信息和日志库是否进入 release 包。取舍是可读的错误信息和小包体之间要平衡，生产环境可以收紧 panic 和日志，开发环境保留调试体验。

Yew 调浏览器 API 有哪些边界？

浏览器 API 仍然受同源策略、权限提示和异步模型限制，Wasm 不能绕过这些安全规则。比如剪贴板、文件系统、摄像头都需要用户授权，离线缓存也受浏览器策略影响。踩坑点是 Rust 类型让代码看起来很可靠，但运行时权限失败仍然要按前端方式处理错误。

小结

Yew 和 WebAssembly 的集成价值在于把 Rust 的可靠性带到前端，而不是神奇地替浏览器消除所有成本。优化时先量化首包、渲染次数和 JS/Wasm 边界调用，再决定是拆包、缓存、Worker 还是减少数据传输。这样做比盲目堆优化技巧更稳。