子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

做 Flutter 一段时间之后，很多人都会遇到一种很拧巴的体验：

• 有的页面一返回，数据全没了
• 有的页面切走再回来，却什么都还在
• Tab 来回切换，还会重复请求接口

于是大家开始怀疑：

Flutter 的页面生命周期是不是很奇怪？

但如果把现象拆开看，会发现问题其实不在“奇怪”，而在我们对路由栈和页面存活方式的理解不够清晰。

路由栈机制，决定了页面是否还活着

Flutter 的页面切换，本质就是对 Navigator 路由栈 的操作。

可以把它想象成一个非常直观的结构：

栈底 → 首页
        ↓
       列表页
        ↓
       详情页 ← 当前显示

当你 push 新页面时：

• 旧页面不会销毁
• 只是被新的 Route 覆盖在下面

而当你 pop：

• 只是把最上层 Route 移除
• 下面那个页面重新露出来

这意味着一件很重要的事：

返回后数据是否存在，首先取决于页面有没有真正被销毁。

如果页面还在栈里，状态自然还在。如果页面已经被替换或移除，那就一定会重新创建。

页面生命周期的真实行为，比想象更“简单”

很多人会把 Flutter 生命周期想得很复杂，其实核心只有两种情况：

情况一：页面仍在路由栈中

• State 对象不会销毁
• 变量值全部保留
• 不会重新执行 initState

这就是为什么有些页面返回后数据还在。

情况二：页面被真正移除

例如：

• 使用 pushReplacement
• 使用命名路由重建
• 父级 Widget 重建导致子树销毁

此时页面会：

• 重新创建 State
• 重新执行 initState
• 数据看起来像“丢失”

所以很多所谓的“状态异常”，其实只是路由使用方式不同。

Tab 切换反复请求接口，问题往往不在网络层

另一个非常常见的场景是：

BottomNavigationBar 切换 Tab，每次都重新请求数据。

这通常说明一件事：

Tab 页面其实被销毁又重建了。

最典型的写法是：

body: pages[currentIndex]

当 currentIndex 改变时：

• 旧页面从 Widget 树移除
• 新页面重新创建
• initState 再次执行 → 重新请求接口

这并不是 Flutter 的问题，而是页面没有被持久保存。

KeepAlive 的真正作用，是“阻止销毁”

很多人第一次接触 KeepAlive，以为它是某种“缓存机制”。

其实更准确的理解是：

让列表或 Tab 中的子页面不要被回收。

常见用法是在 Tab 页面中混入：

AutomaticKeepAliveClientMixin

并返回：

@override
bool get wantKeepAlive => true;

这样切换 Tab 时：

• 页面不会被销毁
• State 仍然存在
• 接口不会重复请求

但这里有一个非常关键的误区：KeepAlive 不是默认就该用的。

如果所有页面都常驻：

• 内存占用会上升
• 页面数量多时会产生压力

所以 KeepAlive 的本质不是“优化”，而是一种明确的取舍。

PageStorage，解决的是“局部状态记忆”

除了整页常驻，还有一种更轻量的需求：

页面可以销毁，但滚动位置要记住。

这就是 PageStorage 的职责。

典型场景：

• 列表页返回后仍停留在原滚动位置
• Tab 切换后列表不跳回顶部

通过为列表提供唯一的 PageStorageKey，Flutter 会自动保存这些短期 UI 状态。

这里可以看到一个很清晰的分层：

• KeepAlive：页面级常驻
• PageStorage：局部 UI 记忆

两者解决的根本不是同一类问题。

页面到底该不该常驻，其实是产品决策

真正困难的，从来不是技术实现，而是什么时候该保留状态，什么时候该重建。

可以用几个很实用的判断标准：

高频往返的页面 → 倾向常驻

• 首页 Tab
• 列表与详情来回切换
• 用户期望“回到刚才的位置”

一次性流程页面 → 应该重建

• 表单提交流程
• 支付成功页
• 引导页

这些页面如果常驻，反而容易产生逻辑混乱。

换句话说：

状态设计，本质是用户体验设计。

总结

Flutter 页面状态看似混乱，其实背后只有几条非常清晰的逻辑：

• 路由栈是否仍然持有页面
• Widget 树有没有销毁 State
• 是否主动选择 KeepAlive 或存储局部状态

当把这些机制真正理解之后，你会发现：

所谓“状态丢失”或“状态常驻”，
很少是框架的问题，
更多是设计阶段没有想清楚。

而一旦页面生命周期与产品预期对齐，很多看似复杂的问题，都会自然消失。