如何排查Flutter应用崩溃及运行时内存耗尽问题？

• 用DevTools做内存快照对比
  打开DevTools的Memory面板，连续做几次内存快照（间隔1-2小时），对比不同快照的heap内存增长趋势，重点关注那些数量持续增加、没有被GC回收的对象类型。比如StatefulWidget实例如果在页面pop后仍大量存在，大概率是泄漏了。

• 检查全局/静态变量的持有问题
  全局变量尤其是持有Widget、Context或大对象的，极易导致内存泄漏——因为全局变量生命周期和App一致，只要被持有就不会被回收。尽量用WeakReference包裹非必要的全局持有对象，状态管理库（Provider/GetX等）避免滥用全局实例。

• 强制检查资源释放逻辑

  • 图片资源：页面销毁时调用ImageCache.clear()清理缓存，或者用CachedNetworkImage这类带缓存管理的库，设置合理的内存缓存上限。
  • 原生资源：WebView、Map、Camera这类PlatformView，必须在Widget的dispose方法里调用对应销毁接口，确保原生侧资源完全释放。
  • 流/状态订阅：StreamSubscription、Bloc/Cubit必须在dispose时执行cancel()或close()，否则订阅会一直持有上下文。

• 排查第三方依赖库
  很多内存泄漏是第三方库的锅，先去查依赖库的GitHub Issues，看有没有其他用户报过长时运行内存泄漏的问题。可以临时移除可疑库，测试是否还出现内存耗尽，逐步定位问题来源。

• 用leak_tracker自动检测泄漏
  集成leak_tracker包，它能自动检测内存泄漏并输出泄漏对象的引用链，帮你快速找到泄漏点。集成后在DevTools的Leak Tracker面板就能看到详细的泄漏报告。

• 代码层面避坑

  • 闭包持有Context：异步操作（Future、Timer）里直接用context，页面销毁后闭包会持有Context导致整个Widget树无法回收。解决方法是在异步回调前先判断mounted，或者用WeakReference<BuildContext>包裹。
  • 无限列表滥用：必须用ListView.builder而不是直接传children列表，后者会一次性创建所有item，长时滚动后内存直接暴涨。

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