获取Flutter Filters组件选中值的最优方案及各方法弊端咨询

我想要创建如下所示的泛型Filters组件：

Filters<int>(
  items: [
    FilterItem(label: 'All', value: 1),
    FilterItem(label: 'Today', value: 2),
    FilterItem(label: 'Unwatched', value: 3),
  ],
),

该组件需要将选中值向上传递到组件树的上层。我知道几种实现方式，但想明确每种方式的弊端：

• 方式1：传递可变选中值（如仅含一个元素的List<T>，代表当前选中值）
  弊端：

  1. 违背Flutter不可变Widget的设计原则，Widget作为配置信息应该是不可变的，用可变List存储状态会导致Widget树与Element树状态不一致，框架无法精准感知状态变化，可能引发UI更新不及时或异常。
  2. 调试难度高，可变对象的修改可在任意位置发生，难以追踪状态变更的源头。
  3. 关于你提到的“值存于WidgetTree而非ElementTree”：这确实存在问题。Widget是临时的配置实例（除非用const修饰），每次重建都会生成新的Widget；而Element才是持有组件状态的持久实例。将可变状态存在Widget中，一旦Widget重建，状态可能被重置或覆盖，且框架无法监听Widget内可变对象的变化，导致UI无法同步更新。

• 方式2：向Filters<T>传递Key以获取公开的选中值T
  弊端：

  1. 耦合度极高，上层组件需依赖子组件的内部实现细节（公开的选中值属性），违反组件封装原则。
  2. 易引发空指针或状态错误，当子组件未初始化、被销毁或重建时，通过Key获取实例可能拿到null或旧状态。
  3. 不符合Flutter状态管理流程，组件间状态传递应通过明确接口（如回调），而非直接访问子组件实例。

• 方式3：使用选中变更时触发的回调void Function(T)
  弊端：

  1. 多层组件传递时会出现“回调地狱”，若上层组件需将状态传递至更远的父组件，需逐层传递回调函数，代码冗余且维护性差。
  2. 无法主动同步获取当前选中值，仅能在回调触发时更新上层状态，若上层需要主动获取子组件当前状态，这种方式无法满足。
  3. 状态完全由上层管理，子组件自身无法持有临时状态，灵活性受限。

• 方式4：通过ValueNotifier<T>进行管理
  弊端：

  1. 需手动管理生命周期，ValueNotifier不会自动绑定组件生命周期，若忘记在组件销毁时移除监听，可能引发内存泄漏。
  2. 状态共享范围难以控制，若多个组件监听同一个ValueNotifier，可能导致不必要的UI更新，或状态变更影响无关组件。
  3. 调试时需追踪ValueNotifier的订阅者和变更源头，相比回调方式，状态流的可见性稍差。

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