技术选型要慎重

最近，我向技术负责人提出建议，希望在新项目中用相对更成熟的 Flutter 替换当前选用的 Tauri，但这一提议被否决了。

否决的理由依然是技术栈统一和学习成本——这些在团队管理中常见的考量因素。

但我提出更换技术，并不是因为个人偏好，而是因为运营那边提出的需求，在当前技术方案下无法实现。

简单来说，运营反馈说希望接入一个第三方平台的 SDK，用来满足运营需求。

这个平台并不支持 Tauri，但提供了 原生 SDK。

因此在理论上，可以通过 编写 Tauri 插件 的方式来适配。

问题也正是从这里开始的。

在接入第三方 SDK 时，项目编译失败，报错是找不到模块。

我查了 Tauri 的 issue，有类似的问题。

于是开始尝试更换其他的 SDK，尝试不同的第三方库。

经过梳理，我怀疑问题出在二进制依赖的处理上。为此，我向 Tauri 官方提交了 issue。

这已经不是我们在使用 Tauri 过程中遇到的第一个难题。

在此之前，已经遇见了诸如 iOS 异步支持，安卓读图片崩溃，iOS 自定义协议导致的 SDK 失效，WebView 适配问题。

再说 WebView。

我目前使用的开发测试机，WebView 版本是 83。公司在用的 Next.js 在这个环境里跑不起来。

原因是最新版 Next.js 默认使用 turbopack，而 turbopack 用到了 WeakRef。但 WeakRef 是在 WebView 84 才支持的。

我去和 Core-JS 反馈过这个问题。为什么 WeakSet、WeakMap 都已经支持了，但 WeakRef 目前没法解决。

经过查询，我了解到确实无法解决，最后只能通过切换构建工具为 Webpack，才把问题绕过去。

我反馈了这些问题给技术负责人，然后是拉了几个开发开会，我演示了下，并没有什么改变，说是先用着，边做边看怎么解决。

那天老板还专门找我，问我什么情况，我说就边做边看。他说如果用 Flutter 要写 Dart，那公司就我一个会了。

但先前项目使用的 Tauri 要写 Rust，开会前，我在会议室准备的时候，他过来还问了。说公司目前会 Rust 的就我和另一个负责桌面客户端的同事。但在我加入那个项目组时，并未显露我会 Rust。也就是说当初项目立项时，在老板看来，公司就只有一个同事会 Rust。

是我多事吗？我如果不说直接切换的话，那可能不会有目前的样子，但出问题了，那么就是我的问题了。

目前，我负责的新项目还是使用了 Tauri，现阶段还在编写静态页面，并未实现任何功能。

而新项目有一些新的需求，以目前的情况来说，是无法实现的。

只能边做边看了。

归根结底，技术选型从来不只是选择一项工具，而是为项目的未来铺路。

可到底又有多少项目有未来呢？