页面反复进入退出后越来越卡，先检查哪些资源？

第一次进入订单页很流畅，来回打开十几次后，滚动开始掉帧，接口请求次数变多，日志也像被复制了一样重复输出。重启 App 后又恢复正常。

这不一定是内存泄漏，也可能是监听器重复注册、定时任务叠加，或者页面压根没有销毁。

核心结论：先检查旧页面离开后是否仍在工作，再检查对象是否仍被持有。排查重点不是看到多少个 dispose，而是每一份有生命周期的资源是否都有明确所有者和对称的释放动作。

先确认页面到底有没有销毁

在 dispose 中记录页面实例标识，然后固定执行“进入—操作—退出”多轮，确认旧实例何时销毁。

如果 dispose 没执行，不要立刻判断 Flutter 有问题。页面可能仍被下面这些结构保留：

IndexedStack 中的 Tab 页面；
使用 KeepAlive 的列表或分页页面；
嵌套 Navigator 中仍在路由栈里的 Route；
仍未移除的 OverlayEntry。

这些页面继续存在不一定是泄漏，但轮询、动画、相机预览可能仍在运行。此时要根据路由可见性或业务激活状态暂停工作，真正销毁时再释放资源。

第一批检查：会自己继续工作的资源

这类问题最容易让页面“越用越忙”：

Timer、轮询任务和延迟回调；
StreamSubscription、WebSocket 和事件总线订阅；
ChangeNotifier、ValueNotifier 及其他 addListener；
WidgetsBindingObserver、RouteObserver 等观察者；
网络请求、Isolate 和可取消的异步任务。

典型现象是每进一次页面，同一事件就多执行一次。内存还没明显上涨，CPU、网络和 Rebuild 已经先叠加。

注册时应保存可以取消的句柄。监听回调也尽量使用命名方法，否则后续很容易拿错函数对象，导致 removeListener 无效。

import 'dart:async';
 
class _OrderPageState extends State<OrderPage>
    with WidgetsBindingObserver {
  late final ScrollController _scrollController;
  StreamSubscription<OrderEvent>? _orderSubscription;
  Timer? _pollTimer;
 
  @override
  void initState() {
    super.initState();
    WidgetsBinding.instance.addObserver(this);
 
    _scrollController = ScrollController()
      ..addListener(_handleScroll);
    _orderSubscription = repository
        .watchOrder(widget.orderId)
        .listen(_handleOrderEvent);
    _pollTimer = Timer.periodic(
      const Duration(seconds: 15),
      (_) => _requestRefresh(),
    );
  }
 
  void _handleScroll() {
    // 根据滚动位置处理页面逻辑
  }
 
  void _handleOrderEvent(OrderEvent event) {
    if (!mounted) return;
    setState(() => currentOrder = event.order);
  }
 
  void _requestRefresh() {
    // 请求层还应处理取消、去重和旧结果淘汰
  }
 
  @override
  void dispose() {
    _pollTimer?.cancel();
    unawaited(_orderSubscription?.cancel());
    _scrollController.removeListener(_handleScroll);
    _scrollController.dispose();
    WidgetsBinding.instance.removeObserver(this);
    super.dispose();
  }
}