为何选择继承UserControl而非其他Flet组件？

Flet文档明确指引创建自定义组件时使用UserControl，它继承自Stack且自带build方法，还能返回非Stack类的组件。但我不理解为什么不能直接继承Container，比如我写的这段代码：

class ArrowButton(Container):
    def __init__(self, arrow_icon: Icons):
        super().__init__(
            height=100, 
            width=100, 
            bgcolor=Colors.WHITE, 
            border_radius=500,
            content=Icon(
                name=arrow_icon,
                size=100,
                color=Colors.BLACK,
            )
        )

我还能给这个类添加方法来更改状态，甚至在另一个项目里基于Container继承构建了一套类似浏览器的自定义标签系统（包含4个自定义类），运行完全正常。

想请教：哪些场景必须使用UserControl而非其他组件？是不是有我忽略的Flutter底层细节？

直接继承Container这类基础组件在简单场景下确实能用，但碰到以下几种情况时，UserControl的优势就体现出来了，甚至是必须的：

• 复杂组件结构的状态管理：如果你的自定义组件需要包含多个子组件，且这些子组件之间有状态联动（比如标签系统里的选中状态切换、内容区联动），UserControl的build方法可以帮你更清晰地管理组件树的重建逻辑。直接继承Container的话，你得手动维护所有子组件的状态更新，代码会越写越混乱。

• 组件生命周期的完整支持：UserControl提供了did_mount、will_unmount等生命周期方法，这些方法在组件挂载/卸载时自动触发，适合做一些初始化（比如数据请求）、清理（比如取消定时器）操作。而Container这类基础组件没有这些生命周期钩子，你得自己找时机处理，容易遗漏关键逻辑。

• 跨平台适配与样式隔离：UserControl作为专门的自定义组件容器，能更好地帮你隔离组件的样式和逻辑，避免和父组件的样式冲突。尤其是当组件需要在不同平台（Web、桌面、移动端）做适配时，build方法里可以根据平台条件返回不同的组件结构，这比直接继承Container灵活得多。

• 符合Flet的设计范式：Flet的组件模型参考了Flutter，UserControl对应Flutter里的StatefulWidget/StatelessWidget，是官方推荐的自定义组件方式。虽然你现在用Container继承能正常运行，但后续Flet版本更新时，基础组件的内部逻辑可能变动，而UserControl作为稳定的自定义组件接口，兼容性会更有保障。

关于你提到的Flutter细节：Flet底层基于Flutter，UserControl本质上封装了Flutter的Widget生命周期和状态管理逻辑。直接继承Container相当于直接操作Flutter的Container Widget，它没有状态管理的封装，所有状态变更都得你手动调用update方法触发刷新，而UserControl会自动处理状态变更后的组件重建，减少手动操作的出错概率。

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