使用Provider替代StatefulWidget管理控制器是否存在问题？

我尝试用Provider创建并使用ScrollController（TextEditingController也打算用同样方式），替代传统StatefulWidget的写法，觉得这种方式更简洁，但同事不认可，想请教这种实现是否存在问题。

我的代码如下：

class Example extends StatelessWidget {
  final List<Widget> children;

  const Example({super.key, required this.children});

  @override
  Widget build(BuildContext context) {
    return ChangeNotifierProvider<ScrollController>(
      create: (_) => ScrollController(),
      child: ListView(
        controller: context.read<ScrollController>(),
        children: children,
      ),
    );
  }
}

这种写法存在几个关键问题： #

• 内存泄漏隐患：ScrollController需要调用dispose()释放内部资源，虽然它继承自ChangeNotifier，但Provider的自动dispose逻辑依赖于ChangeNotifier的机制，一旦Widget树结构复杂（比如Provider范围过大、存在跨页面引用），很可能导致Controller无法被正确回收，引发内存泄漏。
• 生命周期不匹配：StatefulWidget的State生命周期和Widget强绑定，Controller的创建、销毁能精准对应Widget的存活周期。而用Provider的话，Controller的生命周期由Provider的范围决定，后续调整Provider位置时，极易出现Controller和ListView生命周期错位的情况——比如ListView已经销毁，Controller还活着，或者Controller提前销毁导致ListView报错。
• 可读性与团队协作问题：这种写法不符合Flutter的常规实践，团队其他成员看到StatelessWidget里用Provider管理Controller会感到困惑，毕竟Controller和Widget的状态强绑定，放在State里更直观，大家能快速理解它的作用范围和生命周期。
• 上下文风险：context.read<ScrollController>()在当前代码中能正常运行，但如果后续调整Widget结构，不小心在Provider未初始化的位置调用，会直接抛出找不到Provider的错误。而StatefulWidget中直接在State里创建并引用Controller，安全性更高。

更合理的简化写法 #

如果想简化代码，又要规避上述问题，直接用StatefulWidget配合late final的写法其实也很简洁：

class Example extends StatefulWidget {
  final List<Widget> children;

  const Example({super.key, required this.children});

  @override
  State<Example> createState() => _ExampleState();
}

class _ExampleState extends State<Example> {
  late final ScrollController _controller = ScrollController();

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return ListView(
      controller: _controller,
      children: widget.children,
    );
  }
}

内容的提问来源于stack exchange，提问作者Ринат