哈喽，我是老刘
国庆前发了篇文章，主要讲AI协同时代下，Flutter项目的状态管理该如何进行技术选型。
文章链接：2025年Flutter状态管理新趋势：AI友好度成为技术选型第一标准
文章发出来后，很多GetX的拥趸在留言区质疑："老刘，你凭啥没提GetX？" 
还有朋友在微信里私聊我。 
看来这个话题确实戳中了很多人的神经。
今天就专门聊聊GetX这个事儿，说说为啥老刘从来没有推荐过GetX。
如果你也是GetX的忠实用户，先别急着关闭页面。
这篇文章可能会颠覆你的一些认知。
GetX很好，但是大而全的框架不一定适合你
先说明白一点：GetX确实是个好框架。
11k的GitHub星标不是白来的，它确实解决了很多Flutter开发中的痛点。
状态管理、路由管理、依赖注入、国际化、主题切换...
GetX几乎把Flutter开发中能遇到的问题都给你解决了。
这就像一个超级工具箱，什么工具都有，拿来就能用。
但问题恰恰就出在这个"大而全"上。
第一个问题：能力圈陷阱
很多人说GetX简单，上手快。
确实，写个简单的Demo，GetX几行代码就搞定了。
但这种"简单"是有代价的。
你以为你学会了Flutter状态管理，其实你只是学会了GetX的语法糖。
当你遇到复杂的状态管理场景时，你会发现自己对Flutter的原生机制一无所知。
老刘自己面试过很多这样的开发者：
用了一年Flutter，连StatefulWidget的生命周期都说不清楚。
更别提Provider、InheritedWidget这些Flutter的核心概念了。
这就像学开车只会开自动挡，遇到手动挡就抓瞎。
短期看起来效率很高，长期来看是在透支自己的技术能力。
而且真的抛开这些框架，用Flutter原生的功能去搭建一个简单的App真的就会复杂很多吗？
其实不是的。
Flutter本身已经有一套非常优雅的开发理念：
万物皆组件，界面即函数 Everything is a Widget, UI = f(state)
具体来说就是："声明式UI + 响应式编程 + 组件化架构"
只要掌握并遵循这个核心原则，基本上可以搞定90%以上的功能开发。
这也是为什么老刘在路由管理、组件化、数据流等等方面一直推荐大型项目自己封装的原因。
第二个问题：技术绑架
全家桶"式设计的另一个问题是。
一旦你开始用，你会发现很难只用其中一部分。
状态管理用了GetX，路由自然也想用GetX。
路由用了GetX，依赖注入也顺便用GetX。
最后整个项目都被GetX绑架了。
想要局部替换？比重构还难。
我去年接手过一个客户的咨询项目，团队想把GetX的路由部分替换成自己的路由管理方案。
结果发现GetX的状态管理、依赖注入、路由管理之间耦合得太紧密。
牵一发而动全身。
这种技术绑架是非常危险的。
技术选型应该是可插拔的，而不是一锤子买卖。
第三个问题：大型项目的精细化技术选型
大型项目需要的是精细化的技术选型。
状态管理可能需要Bloc的严格架构约束。
路由管理可能需要Go Router的类型安全。
依赖注入可能需要Get_it的轻量级方案。
要知道在每一个细分的方向上，都会有很多专注且做到极致的技术方案。
比如RIverpod，就利用注解和代码生成把状态管理中最常用的模式都用最简化的方式实现了。
能够管理大型项目的技术负责人，一个核心能力就是把项目做精确的拆分然后做合理的技术选型。
所以如果你的项目只有10个页面，"一站式"的技术选型当然没有任何问题。
但是如果你的项目至少有几十个页面，项目负责人仍然上来就用了"一站式"的技术选型，那么大概率他是在做"技术债务"。
真实案例
比如老刘去年去做TDD咨询的一个项目。
项目开始就选择了GetX，但是由于是欧洲客户，客户那边需要单元测试覆盖。
团队后来希望通过TDD的方式，逐步完善项目的测试覆盖率。
但是由于GetX对单元测试并不友好，导致团队在推进TDD的过程中遇到了很多困难。
老刘当时做咨询的过程中也是深度阅读了Getx的源码，帮客户找一个合适的解决方案。
所以之前那篇文章评论区里说因为老刘不懂Getx所以才不推荐的，其实我是因为踩过坑。
老刘的项目进行状态管理选择是如何思考的
说了这么多问题，那到底该怎么选择状态管理方案呢？
老刘总结了自己在进行技术方案选型时遵循的四个原则：
第一：追求简洁和强大的平衡
好的技术方案不是最简单的，也不是最复杂的。
而是在日常开发的简洁性和功能的强大性之间找到最佳平衡点。
真正好的状态管理方案，应该是：
简单场景用起来简单，复杂场景也能hold住。
比如Riverpod，简单的状态管理就是一个Provider。
复杂的异步状态管理，也有AsyncNotifier、StateNotifier等完整的解决方案。
这就像一把好刀，切菜很顺手，切肉也不费劲。
而不是"瑞士军刀"，什么都能干，但什么都不精。
第二：优先考虑把一件事做到极致的框架
老刘有个技术选型的原则：
宁要专精的工具，不要万能的玩具。
最好的方案往往是那些专门解决某一个问题的框架。
比如Bloc，就是专门为状态管理而生的。
它的设计理念非常纯粹：Event -> State。
所有的状态变化都通过事件驱动，状态流转清晰可控。
虽然学习曲线稍微陡峭一点，但是一旦掌握，你会发现它在复杂业务场景下的表现力是非常好的。
再比如Provider，虽然功能相对简单。
与Flutter的生命周期结合得天衣无缝。
这就是专精的力量。
第三：TDD友好性是必要因素
在老刘这边的项目团队，测试驱动开发（TDD）是必选项。
特别是在大型项目中，没有完善的测试覆盖，项目迟早会崩盘。
所以在选择状态管理方案时，一定要考虑它的测试友好性。
Bloc和RIverpod在这方面都做得非常好。
每个Bloc都可以独立测试，状态变化可以精确验证。
反之，全局状态、隐式依赖、私有生命周期管理，这些都会让单元测试变得复杂。
第四：AI友好度是新的必要因素
这是2024年以后技术选型的新标准。
随着AI编程工具的普及，代码的AI友好度变得越来越重要。
什么是AI友好度？
简单说就是：AI能不能理解你的代码，能不能帮你写出正确的代码。
在这方面，遵循标准模式的框架明显更有优势。
比如Bloc的Event-State模式，这是一个非常经典的设计模式。
AI对这种模式的理解度很高，生成的代码质量也更好。
而有很多"黑魔法"的框架，AI就很难理解。
而且这个差距在未来只会越来越大。
因为AI训练数据中，标准模式的代码占绝大多数。
所以从长远来看，选择AI友好的技术方案，就是在为未来的开发效率投资。
GetX争议背后的深层思考：什么才是好的技术选型？
说了这么多，其实GetX争议背后反映的是整个行业的一个深层问题。
我们太容易被"短期效率"迷惑，而忽视了"长期价值"。
这就像投资一样。
追涨杀跌的人，看起来每天都在赚钱。
但真正的投资高手，都在做时间的朋友。
技术选型也是一样的道理。
好的技术选型不是选最热门的，而是选最适合的。
不是选最简单的，而是选最可持续的。
老刘总结的技术选型四大标准：
1. 简洁与强大的平衡 - 既要好用，也要够用
2. 专注度 - 宁要专精的工具，不要万能的玩具
3. 测试友好性 - 没有测试的代码，就是技术债务
4. AI友好度 - 面向未来的开发效率投资
这四个标准，不仅适用于状态管理的选择。
也适用于所有的技术选型决策。
最后送给大家一句话：
"在技术的世界里，没有银弹，只有权衡。"
真正的技术成长，往往发生在那些"看起来更难"的选择里。
因为只有走出舒适圈，你才能看到更大的世界。
这里多说一句，老刘这边的项目通常是考虑团队开发，项目规模相对较大的场景，所以技术选型也是基于这个基础做出的。
对于独立开发者和小型项目来说，"一站式"方案并没有什么问题，反而可能是最优解。
好了，你的项目中，还有哪些"看似便利，实则陷阱"的技术选择？
欢迎在评论区分享你的踩坑经历。
如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。 私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。 可以作为Flutter学习的知识地图。
------ laoliu_dev