Flutter：ChangeNotifier子类持有ScrollController是否属不良实践？

问题1：ChangeNotifier持有ScrollController时的资源释放问题 #

• 结论：ScrollController不会自动释放，必须手动处理dispose，无需将ListViewPage改为StatefulWidget。
• 原因：ChangeNotifier的生命周期由Provider（如ChangeNotifierProvider）管理，当ListViewPage销毁时，Provider会自动调用ChangeNotifier的dispose方法，但ScrollController作为独立资源，ChangeNotifier不会主动释放它。
• 正确做法：在ListViewPageController（ChangeNotifier子类）中重写dispose方法，手动调用ScrollController的dispose：

  class ListViewPageController extends ChangeNotifier {
    final ScrollController sc = ScrollController();
  
    @override
    void dispose() {
      sc.dispose(); // 手动释放ScrollController
      super.dispose();
    }
  }
  

  只要通过ChangeNotifierProvider创建该Controller，页面销毁时Provider会触发此dispose方法，完成资源清理。

问题2：ChangeNotifier是否应该依赖UI代码？ #

• 观点正确性：这个观点是正确的。
• 原因：ChangeNotifier的定位是业务逻辑/状态管理层，职责是处理状态变化与业务逻辑，不应与UI层实现细节耦合。依赖ScrollController、Scrollable这类UI类会带来以下问题：
  • 耦合度高：业务逻辑与UI绑定，后续更换UI组件（如用CustomScrollView替代ListView）时，业务层需同步修改；
  • 测试困难：单元测试业务逻辑时需模拟UI环境，增加测试复杂度；
  • 内存风险：若ChangeNotifier持有BuildContext（如调用Scrollable.ensureVisible需要上下文），易导致上下文泄漏，因为ChangeNotifier生命周期可能长于UI组件。
• Scrollable.ensureVisible是否为不良实践：是的，属于不良实践。该方法是UI层面的滚动操作，应放在Widget生命周期方法（如initState、didUpdateWidget）或UI事件回调中，而非业务逻辑层的ChangeNotifier内。
• 理论重要性：这种分层解耦思想是Flutter开发的核心原则，能让代码结构更清晰，提升可维护性、可复用性与可测试性，符合单一职责原则——业务逻辑只处理数据与状态，UI层只负责渲染与用户交互。

内容的提问来源于stack exchange，提问作者森口万太郎