大家好，我是老刘
Flutter 3.50发布了，配套的是Dart 3.14。
每次大版本更新，大家很容易先去看多了哪些Widget、性能提高了多少。只不过Flutter已经逐步走出了以更新UI组件为主的周期。
这次官方把目标定为"为下一个十年打基础"。整个版本共有188位贡献者参与，其中69位是首次贡献，累计提交超过1200个commit。
官方博客已经写得非常全面，老刘不准备再照着文档复述一遍。咱们只看三件跟日常开发关系紧密的事，原生互操作转正、Web端Wasm扩展、Material和Cupertino正式解耦，以及老项目到底什么时候适合升级。
官方博客地址：flutter.dev/blog/whats-...
一、原生互操作正式转正
这次值得优先关注的变化，是Direct Native Interop进入稳定阶段。
过去Dart调用原生能力，常见做法是走Platform Channel。数据需要序列化，调用通常要走异步流程。普通业务里偶尔调一次问题不大，高频调用或者需要同步返回时，开发者就得多处理一层通信成本。
Flutter 3.50把这条链路往前推了一步。
- FFIgen对Objective-C的支持进入稳定阶段，JNIgen对Java和Kotlin的支持也进入稳定阶段，加上早已稳定的C支持，几条主要原生绑定路线都齐了。
- Dart与平台代码可以直接互相调用，支持同步调用，也支持从后台isolate发起调用。
- Pigeon新增native interop模式，目前仍是预览能力。它底层使用FFIgen和JNIgen生成类型安全绑定，在iOS、macOS和Android上处理数据转换与原生对象生命周期。
说人话就是，Dart和原生代码之间少了一层消息传递，适合对调用频率、同步返回或者原生库集成有明确要求的场景。
官方文档入口：docs.flutter.dev/interop
不过这里要提醒大家。Platform Channel不会因为这个版本发布就失效，已经稳定运行的插件也没必要推倒重写。
如果你的代码中需要高频、低延迟的和原生模块交互，这是个非常值得考虑的方案。
新能力值得研究，旧方案也没必要连夜清零。工程上能稳定交付，才有资格谈先进。
二、Web端Wasm补齐浏览器支持
Flutter Web向WebAssembly迁移已经推进了一段时间，这次主要补上了Safari和Firefox。
执行flutter build web --wasm时，构建结果会同时包含Wasm和JavaScript。老浏览器可以自动回落到JavaScript，不需要开发者单独维护两套产物。
浏览器支持情况如下。
- Chromium系浏览器中，Chrome和Edge 137+已经默认运行Wasm。
- Safari 26.2+开始支持，覆盖macOS和iOS。
- Firefox 147+也开始支持。
- 按照官方重负载Widget基准测试，Safari和Firefox上的帧率可以达到JavaScript的2倍以上。
目前Safari和Firefox还需要在web/flutter_bootstrap.js里手动开启wasmAllowList，后续稳定版本才会默认启用。
官方给出的完整配置如下。
javascript
{{flutter_js}}
{{flutter_build_config}}
_flutter.loader.load({
config: {
wasmAllowList: {
blink: true,
webkit: true,
gecko: true,
},
},
});注意，2倍以上的数据来自官方特定基准，不代表每个业务页面都能获得相同提升。首屏体积、资源加载、图片解码和网络请求仍然会影响真实体验，升级后应该用自己的核心页面做测试。
旧JS互操作库开始退场
dart:html、dart:js、dart:js_util和package:js已经弃用，后续统一迁往dart:js_interop和package:web。新方案可以同时用于JavaScript和Wasm构建，旧库则计划在未来的Dart版本中移除。
想提前排查项目里的旧依赖，可以给构建、运行和测试命令加上--no-deprecated-js-interop。
bash
flutter build web --no-deprecated-js-interop
flutter run --no-deprecated-js-interop
flutter test --platform chrome --no-deprecated-js-interop遇到旧库时，命令会直接失败。这样能把问题提前暴露出来，避免等到正式迁移Wasm时才发现某个间接依赖还停在旧方案。
老刘建议Web项目先在测试分支跑一轮。失败后先看清是自己的代码还是第三方依赖，再决定修改还是等待上游适配，别在发版前临时处理一串连锁问题。
三、Material和Cupertino正式解耦
这件事从Flutter 3.44开始推进，3.47发布了material_ui和cupertino_ui独立包的1.0版本。到了3.50，SDK内的package:flutter/material.dart、package:flutter/cupertino.dart，以及flutter_localizations中对应的本地化代理正式弃用。
现在使用flutter create创建新项目，默认会导入package:material_ui。
存量项目可以通过官方迁移命令处理导入和本地化代理。
bash
dart fix --apply --code=migrate_design_widgetsDevTools自己已经切换到独立包，官方也开始在自己的项目里实际使用这套方案。
老刘关注这项变化，重点不在导入路径改了什么，而在后续的升级方式。
UI组件和SDK捆在一起时，想用一个新组件，往往要连带升级整个Flutter SDK。拆成独立包以后，组件库和SDK可以分开评估，版本升级的风险更容易控制。
代价也同样存在。独立包需要面对更多SDK版本组合，第三方组件库也要跟着适配。项目里的自定义Theme、本地化配置和依赖包，都不能只靠一条命令就算迁移完成。
所以这条命令适合在独立分支执行。跑完以后认真看diff，再回归核心页面和构建流程，别直接在主分支上来一把就提交。
四、老刘为什么仍然看好Flutter的长期投入
不管是Web端继续向Wasm迁移，还是Material和Cupertino解耦，都很符合谷歌过去的做事的调性。
他们习惯先搞一坨大的，等工程实践往前走一段，再把问题逐步拆开。Android过去也经历过类似过程，碎片化问题随之出现。
老刘并不认为拆分本身是一件坏事。
一方面，AI正在降低碎片化治理的机械成本。查找废弃API、批量修改导入、整理依赖清单，这些工作已经比过去轻松不少。不过兼容性验证和线上风险判断仍然需要开发者自己负责。
另一方面，官方愿意把大量人力投入到原生互操作、Web运行能力和组件解耦上。这些工作未必能让演示视频立刻变得好看，却直接关系到项目未来几年的维护成本。
这也是老刘愿意继续投入Flutter的原因。一个技术框架是否值得长期使用，除了看新功能数量，还要看官方是否持续处理那些费力、琐碎又绕不开的基础问题。
按照目前的投入方向，我的判断是未来3到5年，Flutter继续获得官方维护的确定性仍然很高。这是基于当前信号做出的个人判断，大家做技术选型时仍然要结合自己的团队和项目周期。
看一个框架有没有长期价值，别只看发布会演示了什么，还要看它愿不愿意持续偿还基础设施的债。
五、我们该何时升级
老刘的建议仍然沿用过去的保守策略，生产项目先观察两个月。
这两个月主要看三件事。
- 让勇于尝鲜的勇者们帮我们把坑踩一遍。
- 项目使用的第三方插件是否完成适配，尤其是涉及原生互操作、Web旧JS库和设计库的依赖。
- 测试分支的构建与回归结果是否稳定，Android、iOS和Web分别验证，别只看本机能不能跑起来。
现在可以做依赖排查和技术验证，但没必要为了抢版本号直接升级生产环境。升级成本的大头通常藏在插件和历史代码里，SDK本身反而好处理。
到了合适的时机，老刘会在每月例行的Flutter版本选择系列文章里更新建议。
大家静等老刘摔杯为号。
这次Flutter 3.50的三项变化里，你更关注原生互操作、Web Wasm，还是Material和Cupertino解耦？你的项目有没有被某个旧依赖卡住升级？欢迎在评论区留言，咱们一起排一排。
🤝 如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。
🎁 私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。可以作为Flutter学习的知识地图。
💬 : laoliu_dev
📂 老刘也把自己历史文章整理在GitHub仓库里，方便大家查阅。