简介
- 将现有项目编译为web或者webAssembly都有问题。
- 如果通过减法修改现有项目，难度太大，改动太多，还不一定成功。比如，从项目删除GetX的话，跟重写工程也差不了多少。
- 可以考虑做加法，从一开始就考虑三端一套代码，逐步加功能。
Web和WebAssembly的区别
1. 技术定位与编译方式
- Flutter Web
这是 Flutter 对 Web 平台的通用支持，允许开发者将 Dart 代码编译为JavaScript，并通过浏览器 API（如 DOM 或 Canvas）渲染界面。其核心目标是实现跨平台一致性，允许同一套代码在移动端和 Web 端运行
- 编译流程：Dart → JavaScript + HTML/CSS 或 CanvasKit（基于 WebGL 的渲染引擎）。
- 适用场景：单页应用（SPA）、现有移动应用的 Web 移植、交互复杂的图形界面 。
- Flutter WebAssembly
这是 Flutter Web 的进阶技术路线，将 Dart 代码直接编译为 WebAssembly 二进制格式（Wasm），而非传统的 JavaScript。通过结合 WasmGC（垃圾回收支持），Dart 可直接运行在浏览器中，减少对 JavaScript 的依赖 。
- 编译流程：Dart → WebAssembly（通过 dart2wasm 工具链），并结合 Skwasm 渲染引擎（基于 Wasm 的 CanvasKit 实现）。
- 适用场景：高性能要求的应用（如游戏、图形密集型工具），需接近原生性能的 Web 应用 。
2. 性能与体积优化
Flutter Web（传统 JavaScript 模式）
性能瓶颈：JavaScript 解释执行可能导致渲染延迟，尤其在复杂 UI 或高频交互场景 。
体积问题：使用 CanvasKit 渲染时，JavaScript 包体积较大（约增加 1.5MB），影响加载速度 。Flutter WebAssembly
性能提升：Wasm 的二进制格式可直接被浏览器高效执行，减少中间层开销，帧率和响应速度显著提高 。
体积优化：新编译方式（如 Skwasm 引擎）大幅减少代码体积，例如从 2MB 压缩至 500KB 级别 。
多线程支持：通过 Wasm 的线程模型实现并行渲染，减少界面卡顿 。
3. 浏览器兼容性
Flutter Web
支持所有主流浏览器（Chrome、Firefox、Safari 等），但不同浏览器的渲染效果可能因 HTML/CSS 或 CanvasKit 的实现差异而略有不同 。Flutter WebAssembly
Chrome 119+ 和 Firefox 120+ 已稳定支持，但 Safari 尚不支持 。
iOS 浏览器因 WebKit 限制，目前无法运行 Wasm 编译的 Flutter 应用 。
对于不支持 WasmGC 的浏览器，Flutter 会回退到 JavaScript 模式 。
4. 技术架构与工具链
Flutter Web
使用 Dart2JS 编译器将 Dart 转为 JavaScript，依赖浏览器原生 API 和渲染。
HTML 渲染器：轻量级，适合简单 UI。
CanvasKit 渲染器：提供与移动端一致的渲染效果，但体积较大 。Flutter WebAssembly
使用 Dart2Wasm 编译器，结合 WebAssembly 的垃圾回收机制（WasmGC）直接运行 Dart 代码 。
采用 Skwasm 渲染引擎，通过 Wasm-to-Wasm 绑定实现高效的图形渲染 。
工具链要求：Flutter 3.24+，并需配置 HTTP 服务器以支持多线程渲染的响应头 。
5. 开发实践与生态
Flutter Web
成熟度高，社区资源丰富，适合快速迁移现有移动应用到 Web 端 。
插件兼容性问题：部分原生插件可能因 Web 平台限制无法使用，需寻找替代方案 。Flutter WebAssembly
处于快速发展阶段，需关注版本兼容性（如 Dart 3.3+ 的 JS 互操作新机制） 。
未来潜力：随着 WasmGC 的普及，有望成为 Flutter Web 的主流方案，进一步缩小与原生应用的性能差距 。
总结
Flutter Web 是 Flutter 对 Web 平台的通用支持，依赖 JavaScript 编译和浏览器渲染引擎；
Flutter WebAssembly 则是通过 Wasm 实现更高效、更接近原生性能的 Web 应用，但受限于浏览器兼容性。
若需广泛兼容性和快速开发，选择传统 Flutter Web。
若追求极致性能且目标用户使用现代浏览器（如桌面端），优先采用 Wasm 编译模式。
