从事 “Getx 劝退师” 这份奇怪的工作已经有半年了，这是个在外人看来十分不解，但是不得不展开说说的问题。很多国内的 Flutter 开发者第一次学习就开始接触 Getx，在一些视频教程中介绍到：“”

问题汇总

这个部分将持续更新，因为一次总是写不完的，新人的问题总是奇奇怪怪的特别多，相信都可以在这里找到答案，以下是一些典型案例：

“Java 别用 spring android 千万别用jetpack flutter getx 都是垃圾，反正我全用真香”

从设计思想来看，Spring 和 Getx 确实一致的期望开发者只依赖一个框架，以避免使用各种三方库导致质量参差不齐，版本冲突，并可以统一的规范管理。Jetpack 的出现也是为了提供一套官方的最佳实践方案，降低安卓软件的开发成本。

但是显然这不能放在一起类比，Spring 和 Jetpack 背靠的是一家公司，Getx 背靠的只是一个律师兼职的 Flutter 开发者。而且 Spring 和 Jetpack 提供了一整套工具链，包括完善的文档，可拓展可选择的功能，以及完善的测试和验证，Getx 提供了什么呢？四份 md 文档，未经测试且没有注释就发布的功能，以及什么都尝试去做但是并没有做到最好的各种子功能。

如果项目中使用了类似 GetConnect、GetStorge，谁来保证不会出错呢？是靠容易过时的，哪怕出自大佬之手的博客教程吗？而你可以无脑相信 Spring 框架和 Jetpack 框架带来的项目质量的提升和未来的可维护性，因为他们的功能都是模块化的，可拓展的，可测试的，在 Getx 上只能做到的是，能用。

Getx的star数第一

有时候看到这种话真的会很无语，因为我们看一个三方库是否优秀，不会只盯着一个 star 数去看，pub point 和 popularity 同样是很重要的指标，特别是在 pub 评分中有一条， Provide documentation 提供文档，这一项最容易被忽略，因为只需要 20% 的 API 文档覆盖率就可以拿到这部分的分数，而一个可靠的三方库，文档覆盖率应该超过 95% 以保证开发者在使用的时候可以清晰的使用，以保证不会犯错。但是直至2024年4月30日，常用三方库的 API 文档覆盖率为：

注意这里的虽然没有包含分包的统计，但是 Getx 的表现实在是很差，甚至没有 50% 的 API 文档覆盖率。

Flutter Favorite 是被纳入官方推荐的一个集合，无论是 FF 重启前还是重启后，Getx 都没有得到官方的推荐，显而易见它做得不够好，比如上面说道的文档覆盖率，以及没有提及但同样重要的测试覆盖率。一个好的三方库 star 很多很多，有什么意义呢，能说明广大的 Flutter 开发者都喜欢并使用 Getx 吗，我觉得 star 数几乎说明不了什么问题，这就像 Github 上的 star 数一样虚无，riverpod 的 star 数就很少，但依然可以在总多的库中脱颖而出，当选 FF 指标重启后的第一批七个库的其中之一。