“我们当初要是选对了框架，起码能省下三个月！”这是我在复盘时对合伙人说的第一句话。去年年初，我们团队决定开发一款社区类App，目标是小步快跑。在框架选型上，我们面临两个主流选择：React Native（RN）和Flutter。作为技术负责人，我倾向于RN，理由很简单——团队里有人熟悉JavaScript，上手快。但另一个伙伴坚持要用Flutter，认为它的性能和一致性更好。

于是我们做了一个“折中”的决定：用RN先做MVP（最小可行产品）。结果呢？第一个月还算顺利，但进入第二个月，坑就来了。第三方原生模块的兼容性问题层出不穷，每次更新iOS或Android版本，我们就要花两三天去排查和适配。更糟的是，UI在不同设备上渲染不一致，测试报告里“界面错乱”的bug占了40%。用户反馈“卡顿”“闪退”的声音此起彼伏，我们疲于奔命，产品迭代速度几乎停滞。

到了第三个月，我们不得不面对现实：RN的生态虽然成熟，但跨平台一致性差，对初创团队来说维护成本实在太高。痛定思痛后，我们决定推倒重来，全面迁移到Flutter。这次迁移花了四周，过程虽然痛苦，但效果立竿见影。Flutter的“一次编写，处处运行”特性让我们告别了UI适配的噩梦，热重载更是让开发效率翻倍。上线后，应用启动速度提升了30%，崩溃率从5%降到了0.5%。

回过头来看，我的核心教训是：框架选型不能只看团队当前的技术栈，更要看产品的长期稳定性和维护成本。对于初创团队，尤其是资源有限时，Flutter在性能与一致性上的优势，往往能帮你省下“看不见”的隐性成本。如果你也面临同样的纠结，我的建议是——先做个小demo，用真实数据说话，别让“熟悉”成为选型的唯一标准。