过度依赖的隐形成本

在这两个Flutter项目中，开发者几乎为每个功能模块都引入了独立的三方库：从路由管理到网络请求，从状态管理到UI组件，甚至基础的工具函数都依赖外部库实现。这种"拿来主义"导致项目呈现出明显的拼凑感：

路由系统深度绑定第三方框架
状态管理混用Provider/GetX/Riverpod等多套方案
基础工具类直接照搬pub.dev搜索结果前三条的库
这种开发方式看似快速高效，实则会埋下严重的技术隐患。
项目最终变成了三方库的"缝合怪"，开发者的核心工作变成了在不同库的文档和API之间疲于奔命。

二、过度依赖的隐形成本
当然这种现象和项目人员不稳定有直接的关系。因为不需要长期维护，开发完可能就走人了，所以很多人选择自己最熟悉开发速度最快的方案。至于架构设计、公共功能的抽象封装大概率是没有的。
但是一旦项目需要长期迭代下去，随着各种各样需求的加入，前期图省事的隐形成本就开始逐渐显露出来了。

维护风险
很多三方库是个人或者小团队维护，生命周期比较短。
很可能你的项目正如火如荼呢，人家库就停更了。
定制化困境
在需要扩展功能时（如给路由系统增加埋点能力），发现三方库的抽象层级过高，难以在不修改库源码的情况下实现需求。
老刘的团队使用TDD开发模式，对定制化方面的要求会更高一些。
调试黑洞
很多开发引入三方库的目的就是为了减少工作量，因此更不会去关系三方库本身的实现逻辑。
但是一旦碰到bug定位，尤其是需要深入到三方库内部定位的场景，就会非常被动。
技术债利滚利
像状态管理、路由管理这样的核心功能，一旦定下来后期更改的成本是非常高的。
如果一开始随便选择了一个，后期发现不合适自己的项目，需要付出极大的开发和测试成本才能更换。
了解了这些问m.ximalaya.com/sound/842293451/?60=030