关注我公众号的人朋友都知道，昨天在Flutter圈子发生了一件不大不小的事情：《Getx删库跑路了》。
准确地说，不是Getx删库跑路了，是连同作者一同蒸发了。这看起来十分诡异，看起不像是主动行为，个人觉得更像是被封禁了，而不是出于商业原因。至于是不是被Github误封就不好说了，毕竟Github之前也误封过ts版fastmcp。
如果是被封，那么一切看起来没那么糟糕。
大家怎么看？
Getx是一个应用广泛的Flutter框架，是一个庞大且全能的框架，涵盖了状态管理、路由管理、依赖管理等等。某种程度上可以说是"Get在手，天下我有"，但社区对Getx评价是褒贬不一的，最核心的在于：
对于有经验的可能是把利器
对于有新手可能是灾难Getx这个框架把太多的Flutter细节隐藏起来了，这个对于新手极其不友好的。接手Getx满天飞的项目更有可能是一场灾难
我们有个群友就叫：Get劝退师
所以当Getx删库后，除了震惊、shit之外，还有人说：
这玩意就不应该存在，现在删也不晚怎么办？
暂时不用慌
对于现在使用Get的项目，如果没有什么紧急的bug，暂时确实不用慌。首先Github上的Get跑路了，但pub.dev上的不会跑路。
甚至我们可以在pub.dev上下载到源码，实在不行到.pub-cache目录中把Getx源码给捞出来。
有了源码可以把它放到Git或者本地做为依赖。
未来
我相信在不久的将来会有社区的fork出来，毕竟这个框架还是很有热度的，不会就这么突然的沉没在历史的长河中，更何况现在是一个AI的时代。
但也如同上图所示，距4.7.3发布已经4个多月了，而4.7.2也是14个月之前的事了，而最新5.0的候选版本也是14个月前的事了，所以，个人浅显地认Get的活跃度并不能算太高，当然了这也可以和Get趋于稳定有关，但我还是建议迁移到别的库。以下是我推荐的几种方案：
- Notifier + go_router
- Bloc + go_router
- riverpod + go_router
- signals + go_router
至于哪套方案比较好，就仁者见仁智者见智了。大家可以借助AI做迁移，但也需要注意AI有很多时候会把一些边缘case遗漏掉，一定要做好回归测试
启示？
启示就是如果能不依赖第三方，就不依赖，如果非要依赖，那就做好第三方依赖的隔离。
完全不用第三方看起来更像是天方夜谭。
类似话题我在之前的推文中也聊过。这其实不仅仅是Flutter的问题，是几乎软件项目都会面临的问题：跑路的跑路，API破坏掉的破坏掉。
所以，做好依赖的隔离显得尤为重要，即使现在有了强大AI，我也相信你也不太愿意在一次迁移中看到300多的文件变动吧......
所以，如果你非要我给你推荐一个Getx的迁移方案，我会首推Notifier + go_router，原因不仅是这Flutter 官方架构方案，也是对外依赖比较小的一种方案。我也有用到了provider，但是用来做DI，仅在最外层使用，如果provider有一天不维护，迁移起来不会太痛苦。
结语
嘴笨，不知道说什么。