为何多数Flutter代码用Provider而非GetX/Riverpod/Bloc？如何选型

Provider成为教程、开源项目首选的核心客观原因 #

• 官方背书的稳定性：Provider 由Flutter核心团队成员主导开发维护，2019到2023年期间，Flutter官方的入门Codelab、官方文档示例里的状态管理实现直接用的就是它，这么多年下来API几乎没有大的破坏性变更，已知Bug都有成熟的规避方案，完全不用担心库突然停更、版本升级跑不起来的问题，是社区公认的不会出错的选择。
• 学习门槛足够低：Provider 没有搞一堆花里胡哨的封装，核心就是对Flutter原生InheritedWidget能力的轻量化包装，所有逻辑都跟着Flutter本身的组件生命周期、上下文机制走，没有藏在黑盒里的"魔法"操作，新手只要搞懂Flutter本身的组件刷新、状态传递逻辑，就能完全吃透它的原理，出了问题不用翻半天库的源码找原因。
• 内容沉淀足够多：从普及到现在已经5年多，不管是新手踩坑记录、生产环境最佳实践、常见问题解决方案，网上一搜一大把，教程作者选它讲课，不用额外解释一堆库自己定义的特殊规则，学习者跟着敲代码也不容易因为版本不对、逻辑不理解卡壳，自然愿意用它做教学。
• 开发者路径依赖：Flutter生态的状态管理方案是一步步迭代过来的，早期大家用setState、ScopedModel，Provider出来之后因为简单稳定快速普及，大部分早一批入行的Flutter开发者学的第一个规范化状态管理方案就是它，只要项目里用着没出大问题，不管是个人开源项目还是公司商业项目，都不会随便换技术栈，存量项目越积越多，自然占比最高。

其他状态管理方案存量占比低的客观原因 #

• GetX：它根本不是一个纯状态管理库，是把路由、依赖注入、弹窗、国际化、常用工具方法全打包在一起的"全家桶"框架，封装得特别深，很多逻辑完全绕开了Flutter原生的生命周期管控，之前不少开发者踩过内存泄漏、路由栈乱掉、状态莫名刷新的坑，中大型团队考虑到后期可维护性，基本不会全量引入；再加它版本迭代的时候经常改API，不同版本的用法差很多，社区也没形成统一的最佳实践，教程作者如果用它讲课，可能刚录完教程版本更了，跟着学的人代码跑不起来，自然相关的教学内容少。
• Bloc：走的是严格分层的架构路线，强制把事件、状态、业务逻辑拆得清清楚楚，好处是多人协作的时候代码规范统一，坏处是样板代码特别多，写个简单的计数器都要搭好几层结构，学习门槛高，对新手、做小项目快速迭代的场景来说太重了，所以入门教程很少选它。
• Riverpod：是Provider的原作者做的下一代方案，解决了Provider原来必须依赖context、类型不安全这些老问题，设计上比Provider更合理，但它1.0稳定版2022年才正式发，比Provider晚了快3年，现在还在生态积累、老项目迁移的阶段，所以内容存量暂时还没追上Provider。

新手选型参考 #

• 刚入门Flutter的时候优先学Provider：学它的过程其实就是在搞懂Flutter本身的状态传递逻辑，不是学某个第三方库的专属用法，把它搞明白之后，再学其他任何状态管理方案都很快，不会被绑定在某一个库上。
• 如果是自己写小Demo、做个人小项目想快点出活，可以按需用GetX的部分能力，不建议一上来就全量用它的全家桶，不然遇到黑盒问题排查起来非常麻烦。
• 等你把Flutter基础打牢，准备去公司做中大型商业项目的时候，可以再学Riverpod或者Bloc，这两个方案最近几年在生产级项目里用的人越来越多。

内容的提问来源于stack exchange，提问作者GoodMan