重写setState并加入mounted检查是否属于不良编程实践？

首先直接给出结论：这种做法不算严格意义上的“不良实践”，但存在不少潜在隐患，需要结合场景权衡使用，更推荐用更清晰的替代方案。

这种重写方式的优点 #

• 减少重复代码：不用在每一处异步回调的setState前都写if (!mounted) return，适合页面有大量异步操作后更新状态的场景。
• 统一错误防护：避免因遗漏mounted检查导致的setState() called after dispose()报错。

潜在的风险和问题 #

• 违反直觉，增加维护成本：其他开发者（包括几周后的你）看到setState调用时，默认会认为它会正常执行状态更新，重写后行为被悄悄改变，排查问题时容易忽略这个隐藏逻辑。
• 限制特殊场景需求：虽然少见，但如果后续需要在组件unmounted后执行某些关联操作（比如清理临时数据），重写后的setState会直接跳过，可能导致逻辑遗漏。
• 框架兼容性隐患：如果Flutter未来对setState的内部实现做调整，重写的逻辑可能会和新的框架行为冲突，引发意外问题。

更推荐的替代方案 #

1. 封装安全更新方法
   不用重写原生setState，而是自己封装一个safeSetState方法，行为明确，可读性更强：

   void safeSetState(VoidCallback fn) {
     if (mounted) {
       setState(fn);
     }
   }
   

   调用时直接用safeSetState(() { /* 状态更新逻辑 */ })即可，既减少重复代码，又不修改原生方法的默认行为。

2. 使用Flutter原生异步组件
   优先用FutureBuilder或StreamBuilder来处理异步状态更新，这类组件会自动监听组件的生命周期，当组件unmounted时不会触发重建，从根源上避免这类问题，这也是Flutter官方推荐的异步状态管理方式。

3. 使用专业状态管理库
   如果页面状态逻辑复杂，直接用Provider、Riverpod、Bloc等状态管理库，这些库都内置了完善的生命周期管理机制，会自动处理组件销毁后的状态更新问题，不需要手动写mounted检查。

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