Flutter开发中页面应继承StatelessWidget还是StatefulWidget？

首先纠正一个常见的认知偏差：StatelessWidget 并不是完全无法和用户交互，只是它本身不持有可变状态，所有展示属性都是构造阶段传入的固定值，交互触发的状态变更需要通过父组件传递或者其他状态管理方案实现，本身没有 setState 能力更新自身渲染。

你可以按照下面的标准判断页面要继承哪种Widget：

选择 StatelessWidget 的场景 #

• 页面所有展示内容完全由路由跳转时传入的参数决定，没有需要额外修改的本地状态。比如纯展示的商品详情页、公告通知页，所有内容都是上层传递的固定值，没有点赞、编辑这类会改变页面展示的交互
• 页面的所有状态都托管给外部状态管理库（如Provider、Riverpod、Bloc等），页面本身只负责监听数据变化并渲染，不需要持有私有状态。这种场景下就算页面有交互，状态更新逻辑都在状态管理层处理，页面用 StatelessWidget 完全可以满足需求
• 页面是纯静态展示页面，没有任何会触发界面更新的交互，比如隐私政策页、用户协议页、纯文本的帮助说明页

选择 StatefulWidget 的场景 #

• 页面需要持有只在当前生命周期内有效的私有可变状态，且这个状态不需要共享给其他页面、也不需要持久化存储。比如页面内开关的选中状态、输入框的临时输入内容、Tab栏的选中下标、动画控制器这类不需要对外暴露的局部状态
• 页面需要用到Widget生命周期回调做自定义逻辑，比如需要在 initState 中发起页面初始接口请求、在 dispose 中销毁定时器/控制器等资源，这类生命周期回调只有 StatefulWidget 对应的 State 类才能提供
• 页面有频繁的局部更新需求，用自带的 setState 做局部刷新的性能优于全链路状态管理触发的页面重绘，比如包含动画、高频交互的自定义页面

实用小建议：前期拿不准的时候可以先实现为 StatelessWidget，后续需要State相关能力时直接用IDE的一键重构功能转成 StatefulWidget 即可，改造成本极低，不需要在项目初期过度纠结选型。

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