前言

GetX 不论是在 pub 上还是在 Github 上都非常受欢迎，作为一个功能丰富的插件，它帮我们搞定了如下事情：

主题切换：比如深色模式切换；
多语言：可以通过配置 Map 搞定多语言；
弹窗提醒：包括了 SnackBar 和对话框；
路由：无需 Context 的路由跳转；
离线存储：不依赖原生的key-value 存储组件的离线存储 GetStorage；
状态管理：快速接入的响应式状态管理；
工具类：例如表单验证工具，获取系统参数（平台类型，屏幕尺寸等）；
依赖注入容器：使用简单的 put 和 find 方法完成容器对象的注册和获取；
网络请求：可以使用 GetConnect 完成网络请求。

感觉使用 GetX 这一个插件可以把应用大部分的基础事情做完，难怪大家说 GetX 真香了！
没有十全十美的事情，那么 GetX 有什么缺陷吗？我们看看国外的朋友怎么说。

GetX 作者背景

GetX 的发起者我特意调研了一下，这位叫 Jonny Borges 的兄弟目前在一家互联网公司（官网：http://iris.finance）就职，主要做股市社交 App。公司规模不大，Jonny Borges也是创始团队之一，看 GitHub 的履历应该是全栈大神。值得一提的是这家公司貌似有两个中国人（或华裔）。

他们的 App 宣传图如下，看界面还是很不错的。我也下载了他们的应用，虽然支持中国大陆手机注册，但是迟迟收不到验证码，只能作罢。

ba635dcbc67346cfa67595ff4a241e13_tplv-k3u1fbpfcp-zoom-1.jpg

当然，目前 GetX 的参与者已经有130多人了，未来的发展应该会更加好。

GetX的客观评价

之所以给这“客观”二字加上引号，是因为发现写这篇文章的作者自己出了个状态管理插件，叫做：flutter_meedu，要对标 GetX，因此至于是否真的客观大家自己感受。下面的内容来自原文的翻译，考虑阅读体验，做了部分删减和修改。

使用 GetX 的导航需要使用自定义的 MaterialApp 或 CupertinoApp，也就是我们需要使用 GetMeterialApp 或 GetCupertinoApp 包裹应用才能够在页面跳转时无需使用 BuildContext。对应用的侵入性比较强。
SnackBar、对话框和导航的使用上不太合理。在这些实现的内部使用了静态的 context，这使得单元测试没法直接晚餐，而需要使用 widget testing配合完成。
get_connect 插件集成了 REST API 请求和 GraphQL 客户端。这有点多余，一般的应用不会二者都用，这会导致插件部分功能多余（推荐网络请求还是用 Dio）。
依赖注入和热重载问题（这点本人也发现了）：GetX 的依赖注入还不太成熟，如果依赖对象改变后（比如修改了依赖对象类型，增加了依赖对象），直接热重载会报错，这个时候往往需要 reload 才行。
注释和文档比较糟糕（这点有同感）：源码很多地方缺少注释，导致未来的维护可能会比较麻烦。而官方文档相对也不是很完善，导致使用者需要自己摸索（确实，写这个系列的时候好多地方都是自己摸索出来的）。
代码组织性比较差：如果去阅读源码，会发现一个文件会有数百行，多个类、函数、变量都混在一个文件中。同时部分方法的命名也需要改进，比如路由的 Get.to，Get.toNamed，Get.offNamed，依赖注入的 Get.put，Get.lazyPut 等，这些方法名称如果不阅读文档很难推断出具体的功能。如果在方法和 Get 之间加一个模块名称会更好理解，比如 Get.router.to，Get.dependencies.put。
很多代码没有经过测试：由于 GetX 覆盖的功能实在太多，很难做到每个功能特性都做完善的测试，这会使得其中可能存在隐藏的 Bug。
使用 GetX 的建议：建议只使用必要的模块，比如 GetX 的状态管理、响应式编程和依赖注入，而像导航和绑定这类的功能要慎用。

虽然有上述的问题，但 GetX 不失为一个很强大的插件，只是在实际应用中需要小心，对于全盘接收 GetX 的用法要注意其风险。

总结

从国外这位作者的评价和本人的实际体会来看，这位作者说得还是相对客观的。随着 Flutter 生态的日益完善，实际在 Flutter 的开发中有很多 GetX 功能特性的替代者，因此建议来说不要为了简化开发而全盘使用，这样一旦GetX出现问题或者升级跟不上可能导致整个应用的维护升级都面临巨大的工作量。