Dioxus

它解决什么问题

Rust 生态里的界面开发长期处于碎片化状态：写桌面端要挑一套渲染后端，写移动端又得换工具链，Web 端往往只能靠包裹 HTML 或手写 WASM 胶水层。结果是同一款产品要维护三套代码、三份构建脚本、三种调试方式。Dioxus 想解决的是一套 Rust 代码同时跑在 Web、桌面和移动端的问题，同时保留 Rust 的性能与类型安全。

它是怎么工作的

• 统一的渲染抽象：组件用 rsx! 宏描述，写法接近 React 的 JSX；框架负责把组件树交给不同后端渲染，包括 web-sys、WebView、服务端渲染（SSR）、LiveView，以及实验性的 wgpu 渲染器。
• CLI 驱动的工作流：dx serve 负责本地预览与热重载，dx bundle 输出经过压缩和优化的产物，例如 .wasm 压缩、.avif 图片生成和代码压缩。
• 原生能力直连：移动端通过 --platform android 直接跑在模拟器或真机上，并通过 JNI 调用原生 API，不需要中间的胶水层。
• 可嵌入：可以把 Dioxus 嵌入到 Bevy、WGPU 项目中，或运行在嵌入式 Linux 上。

适用边界与注意点

• wgpu 渲染器仍在实验阶段，适合尝鲜，不建议作为生产环境的依赖。
• LiveView 和 SSR 的交互模型与传统 Web 应用不同，前后端状态同步需要重新设计。
• rsx! 宏在编译期展开，报错信息有时不够直观，需要掌握宏展开的调试方法。
• 移动端调试依赖 JNI 调用，遇到原生层问题时要同时排查 Rust 和 Java/Kotlin 两层。