Flutter无需BuildContext的状态管理方案存在弊端的具体实例问询

目前Flutter有非常多的状态管理方案，可参考官方的状态管理选项说明。
为了避免主观倾向性回复，以下均为实际开发中可佐证不需要BuildContext的状态管理方案存在弊端的具体实例，供参考。

支持使用无需BuildContext的状态管理包的一个常见论点如下：

需要通过BuildContext才能访问相关对象的设定，会导致业务层无法访问这些对象。

• 内存泄漏风险：绝大多数无BuildContext的状态管理方案都以全局单例形式实现，默认生命周期和应用进程完全一致。如果状态实例持有了页面级的临时数据、已销毁页面的UI更新回调，且没有配套的手动清理机制，相关资源会长期驻留内存无法释放。实际开发中曾遇到重复进入、退出某个带复杂表单的页面10次，内存直接上涨200M的问题，排查了2天才定位到是全局状态持有了表单的临时上传文件引用没有清理。依托BuildContext的状态管理可以绑定页面/Widget的生命周期，Widget销毁时自动释放状态实例，完全不会有这类问题。
• 同类型页面状态串扰：多个栈内同类型页面共用同一个全局状态实例时，如果没有手动做唯一标识隔离，很容易出现状态同步异常。电商类项目开发中曾遇到过连续打开5个不同商品的详情页，在最后一个详情页点击收藏按钮，栈内其余4个详情页的收藏按钮状态全部跟着变更的问题，原因就是全局详情状态实例没有按商品ID做分片隔离。如果用绑定BuildContext的状态管理，每个详情页自己维护独立的状态实例，天然就不会出现这类串扰问题。
• 单元测试成本提升：全局单例形式的状态默认不会自动重置，单元测试时前一个用例修改的状态会直接影响后一个用例的执行结果，需要为每个用例额外编写所有依赖的全局状态的重置逻辑，增加了大量无用的样板代码。而依托BuildContext的状态可以在每个测试用例单独构建状态树，不同用例的状态完全隔离，不需要额外处理。
• 热重载效率降低：部分无Context的全局状态管理实现，热重载时不会重新初始化实例，修改状态相关的业务逻辑后经常出现热重载不生效的问题，必须冷重启应用才能看到修改结果，长期下来会拖慢开发效率。
• 上下文相关能力调用不稳定：如果状态逻辑里需要调用和BuildContext绑定的能力（比如展示SnackBar、页面跳转、获取当前主题/本地化配置），无Context的状态管理需要额外维护当前活跃的顶层Context引用，很容易出现引用的Context已经被销毁导致的空指针崩溃，稳定性远低于直接在Widget树中通过Context调用对应能力的实现方式。

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