子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）
大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学"明白"，也用"到位"
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
-
- 引言
- 路由栈机制，决定了页面是否还活着
- 页面生命周期的真实行为，比想象更"简单"
- [Tab 切换反复请求接口，问题往往不在网络层](#Tab 切换反复请求接口，问题往往不在网络层)
- [KeepAlive 的真正作用，是"阻止销毁"](#KeepAlive 的真正作用，是“阻止销毁”)
- PageStorage，解决的是"局部状态记忆"
- 页面到底该不该常驻，其实是产品决策
- 总结
引言
做 Flutter 一段时间之后，很多人都会遇到一种很拧巴的体验：
- 有的页面一返回，数据全没了
- 有的页面切走再回来，却什么都还在
- Tab 来回切换，还会重复请求接口
于是大家开始怀疑：
Flutter 的页面生命周期是不是很奇怪？
但如果把现象拆开看，会发现问题其实不在"奇怪"，而在我们对路由栈和页面存活方式的理解不够清晰。
路由栈机制，决定了页面是否还活着
Flutter 的页面切换，本质就是对 Navigator 路由栈 的操作。
可以把它想象成一个非常直观的结构：
栈底 → 首页
↓
列表页
↓
详情页 ← 当前显示当你 push 新页面时：
- 旧页面不会销毁
- 只是被新的 Route 覆盖在下面
而当你 pop：
- 只是把最上层 Route 移除
- 下面那个页面重新露出来
这意味着一件很重要的事：
返回后数据是否存在，首先取决于页面有没有真正被销毁。
如果页面还在栈里，状态自然还在。如果页面已经被替换或移除，那就一定会重新创建。
页面生命周期的真实行为，比想象更"简单"
很多人会把 Flutter 生命周期想得很复杂，其实核心只有两种情况：
情况一：页面仍在路由栈中
- State 对象不会销毁
- 变量值全部保留
- 不会重新执行 initState
这就是为什么有些页面返回后数据还在。
情况二：页面被真正移除
例如：
- 使用
pushReplacement - 使用命名路由重建
- 父级 Widget 重建导致子树销毁
此时页面会：
- 重新创建 State
- 重新执行 initState
- 数据看起来像"丢失"
所以很多所谓的"状态异常"，其实只是路由使用方式不同。
Tab 切换反复请求接口，问题往往不在网络层
另一个非常常见的场景是：
BottomNavigationBar 切换 Tab，每次都重新请求数据。
这通常说明一件事：
Tab 页面其实被销毁又重建了。
最典型的写法是：
dart
body: pages[currentIndex]当 currentIndex 改变时：
- 旧页面从 Widget 树移除
- 新页面重新创建
- initState 再次执行 → 重新请求接口
这并不是 Flutter 的问题，而是页面没有被持久保存。
KeepAlive 的真正作用，是"阻止销毁"
很多人第一次接触 KeepAlive，以为它是某种"缓存机制"。
其实更准确的理解是：
让列表或 Tab 中的子页面不要被回收。
常见用法是在 Tab 页面中混入：
dart
AutomaticKeepAliveClientMixin并返回：
dart
@override
bool get wantKeepAlive => true;这样切换 Tab 时：
- 页面不会被销毁
- State 仍然存在
- 接口不会重复请求
但这里有一个非常关键的误区：KeepAlive 不是默认就该用的。
如果所有页面都常驻：
- 内存占用会上升
- 页面数量多时会产生压力
所以 KeepAlive 的本质不是"优化"，而是一种明确的取舍。
PageStorage，解决的是"局部状态记忆"
除了整页常驻，还有一种更轻量的需求：
页面可以销毁，但滚动位置要记住。
这就是 PageStorage 的职责。
典型场景：
- 列表页返回后仍停留在原滚动位置
- Tab 切换后列表不跳回顶部
通过为列表提供唯一的 PageStorageKey，Flutter 会自动保存这些短期 UI 状态。
这里可以看到一个很清晰的分层：
- KeepAlive：页面级常驻
- PageStorage：局部 UI 记忆
两者解决的根本不是同一类问题。
页面到底该不该常驻，其实是产品决策
真正困难的，从来不是技术实现，而是什么时候该保留状态，什么时候该重建。
可以用几个很实用的判断标准：
高频往返的页面 → 倾向常驻
- 首页 Tab
- 列表与详情来回切换
- 用户期望"回到刚才的位置"
一次性流程页面 → 应该重建
- 表单提交流程
- 支付成功页
- 引导页
这些页面如果常驻，反而容易产生逻辑混乱。
换句话说：
状态设计，本质是用户体验设计。
总结
Flutter 页面状态看似混乱，其实背后只有几条非常清晰的逻辑：
- 路由栈是否仍然持有页面
- Widget 树有没有销毁 State
- 是否主动选择 KeepAlive 或存储局部状态
当把这些机制真正理解之后，你会发现：
所谓"状态丢失"或"状态常驻"，
很少是框架的问题，
更多是设计阶段没有想清楚。
而一旦页面生命周期与产品预期对齐，很多看似复杂的问题，都会自然消失。