Flutter for OpenHarmony，垃圾分类指南App，底部导航栏——这三个关键词放在一起，就是一个非常典型的跨端实战样本。我拿到这个标题时第一反应是：这活儿看起来不难，但真要跑通却有不少细节藏在后面。因为Flutter本身跑在Android/iOS上已经很成熟，但跑到OpenHarmony平台，就涉及SDK选型、工具链配置、插件适配这些平时不太会碰到的坑；再加上“垃圾分类指南”这个应用场景非常贴近日常生活，数据模型简单、逻辑清晰，用来做平台迁移实践的载体再合适不过。而底部导航栏呢，又是所有工具类App都绕不开的导航骨架，选它作为实战落点，能同时覆盖页面组织、状态保持、图标交互和安全区适配这些基础能力。
这篇文章就是围绕这三个关键词展开的完整实战记录。适合两类人看：一是想了解Flutter在OpenHarmony上到底能不能干活、坑有多深的移动端开发者，二是正好在做一个带有底部导航结构的工具类App、想找个可参考框架的初学者。我会把从环境搭建、工程初始化，到底部导航栏核心代码落地，再到垃圾分类四个页面逐个实现的全过程都过一遍，最后整理一份我实测踩过的问题清单。整个过程不算复杂，但价值就在那些文档里不会写清楚的细节里。
1. 项目背景与整体思路解析
1.1 标题里的三层信息到底在说什么
先把标题拆开看：“Flutter for OpenHarmony”说明的是技术栈和运行平台，“垃圾分类指南App”是具体业务场景，“底部导航栏实现”则是这次实战要攻克的核心功能点。三层信息叠加，其实构成了一条完整的项目主线：在一个相对较新的系统平台上，用Flutter这个跨端框架，去实现一个真实可用的工具类应用，并且先把最关键的导航框架落地。
Flutter for OpenHarmony的背景有必要先说清楚。Flutter本身是跨平台的UI框架，一套Dart代码可以渲染到Android、iOS、Web、Windows、macOS和Linux上。而OpenHarmony作为一个开源操作系统，起步阶段最大的短板就是应用生态，因此社区一直在做Flutter引擎的适配移植。现在这个适配已经达到了可以开发中小型应用的程度，这对开发者来说是一个特别有价值的信息：你会Flutter，就多了一块可以落地的平台，而不是一切从零学起。
垃圾分类指南这个场景选得也很有讲究。它不像电商、社交那样需要复杂的后端和实时数据，核心就是一套可查询、可浏览的分类规则与物品数据。这种轻业务、重数据展示的形态，正是评估一个新平台开发体验的最佳样本。你不需要被业务复杂度干扰，可以专心观察框架本身在目标平台上的运行表现。
1.2 为什么非要绕一圈用Flutter，而不是直接原生开发
OpenHarmony原生开发有自己的一套语言和UI框架，能力并不弱。那为什么还要用Flutter？这个问题我在项目立项之前认真权衡过，最终说服我的理由有三点。
第一是团队技术复用。我身边很多做移动端的团队，现有代码和人力都沉淀在Flutter或React Native这类跨端方案上。要进入OpenHarmony生态，与其让整个团队重新学一套语言和UI框架，不如用Flutter做一次平台适配投入，学习曲线会平缓很多。第二是业务跨端统一。很多工具类应用不只是做一个平台，而是要同时覆盖手机、平板、甚至桌面端。Flutter的代码复用比例非常高，UI层写一遍，多个平台跑，长期维护成本更可控。第三是Flutter自己的渲染和交互能力。它的自绘引擎保证了UI在各类设备上有一致的表现，底下系统怎么换，渲染层都是你那套Widget树说了算。
但我也把丑话说在前面。Flutter for OpenHarmony目前的成熟度跟Android/iOS比还是要差一截的。最典型的问题就是插件生态：pub.dev上有很多包只实现了Android/iOS平台，并没有ohos平台的实现，用了就编译不过。另外包体积偏大、首次启动偏慢这些问题在OpenHarmony上同样存在，有的甚至更明显。所以如果业务本身高度依赖OpenHarmony系统能力，比如分布式流转、硬件调用，那就老老实实走原生路线；如果业务就是一个数据展示类的工具App，Flutter这个方案完全值得考虑。
1.3 App功能结构拆解：四个Tab对应四条业务线
基于垃圾分类指南这个业务，我把App规划成了四个主模块，正好对应底部导航栏的四个入口。
“指南”模块是首页，展示可回收、有害、厨余、其他四大垃圾类别，每个类别是一张卡片，点击进入类别下的物品列表，再点物品进入详情页，详情里有分类说明、处理建议、注意事项。“查询”模块做一个全局搜索框，输入垃圾名称或关键字，实时过滤本地数据并展示分类结果。“专题”模块放一些科普文章，比如“厨余垃圾处理误区”“有害垃圾为什么必须单独收集”这类内容，文章用本地资源维护，后续可以换成后端接口。“我的”模块先做个人中心的基本框架，包括收藏列表、关于页面、设置入口，为以后接入账号体系留位置。
这四个模块对应的数据量都不大，页面结构也相似，用一套底部分栏骨架把它们串起来特别合适。更重要的是，这种结构能很好地验证底部导航栏的关键能力：Tab来回切换后页面状态是否保留、每个页面是否可以独立开发互不干扰、二级页面压栈后返回是否还能回到原来的Tab位置。框架稳了，后面加功能才不慌。
2. 环境搭建与工程初始化
2.1 Flutter for OpenHarmony的SDK选型和环境变量配置
要开发Flutter for OpenHarmony，第一件事就跟平时不一样：不能直接拿标准Flutter SDK用，而是需要支持ohos平台的特定分发版本。这个版本怎么找、怎么下，资料分散在不同文档里，很多人第一关就卡住了。
我的建议是，先确认当前需要的Flutter SDK版本，再通过官方渠道下载对应的ohos支持版。下载之后解压到一个没有中文和空格的路径，比如我放在D:\dev\flutter_ohos。这不是强迫症，而是Flutter工具链对路径里的中文和空格处理不好，遇到莫名其妙构建失败的时候，十有八九是路径问题。解压完成后，把flutter/bin目录加入系统PATH，然后在命令行执行flutter doctor，看看工具链是否被正确识别。
有一个特别容易踩的坑：电脑上如果同时装了标准版Flutter和ohos版Flutter，PATH里到底指向哪个版本一定要心里有数。我就见过有人明明配好了ohos环境，跑命令时却调用了旧版SDK，报错信息完全看不懂来历。建议用环境变量管理工具或者写个简单的切换脚本，避免多版本打架。
2.2 创建工程并理解ohos目录结构
环境变量配好之后，创建工程这一步其实很快：
flutter create --org com.example --project-name garbage_guide --platforms ohos .执行这条命令的时候，建议在项目根目录先建好一个空目录再进入执行，这样不会多出一层嵌套。如果当前Flutter SDK确实支持ohos平台，生成目录里会多出一个ohos/子目录，它承担的角色跟安卓工程里的android/目录是一样的：负责OpenHarmony侧的打包、签名、权限配置。
整个项目的目录结构我规划成这样：
lib/ main.dart pages/ home_page.dart search_page.dart article_page.dart mine_page.dart detail_page.dart models/ garbage_item.dart data/ garbage_data.json ohos/ entry/ ... pubspec.yaml页面、模型、数据资源分开存放，这是Flutter项目的常规做法，但很多人一开始图省事把一堆代码塞在main.dart里，后面就后悔了。页面多了之后，清晰的目录结构带来的维护成本下降，比一开始省那几分钟重要得多。
2.3 首次运行：先让空工程在设备或模拟器上跑起来
工程创建之后我强烈建议先干一件事：把空工程跑起来，确认工具链路通了再写业务代码。比如你先跑一下flutter devices，看看能否识别到OpenHarmony设备或模拟器。如果识别不到，大概率是IDE里的OpenHarmony插件没装好，或者模拟器没启动。
确认设备后开始运行：
flutter run -d <device-id>首次构建会花比较长时间，因为要下载依赖、编译原生工程，同时OpenHarmony侧也要做一次构建，这个过程看起来像卡住了，其实CPU和磁盘都在疯狂工作。我头一次跑等了三五分钟也没反应，一度怀疑配置错了，后来盯着任务管理器才发现编译线程是满的。所以跑之前有点耐心，把首次构建的预期时间留够。
还要说一句调试日志的问题。在OpenHarmony平台上，Flutter的print输出不一定直接出现在IDE的Flutter控制台里，很多时候需要看OpenHarmony侧的系统日志才能找到Dart侧的运行日志。具体查看方式我在后面的问题排查部分会说，但最好从现在开始就形成习惯，确认自己打印的日志到底去了哪里。
3. 底部导航栏实现：核心环节拆解与代码落地
3.1 组件选型：NavigationBar和BottomNavigationBar到底选谁
Flutter里做底部导航栏，经典方案是BottomNavigationBar，但Material 3时代官方更推荐NavigationBar。这两个组件的核心定位是相同的：展示一组目的地，让用户在不同页面之间切换。区别主要体现在视觉和交互细节上：NavigationBar默认带圆角胶囊指示器、更大的点击区域、更现代的动效，而且跟你启用useMaterial3之后的全套Material风格更协调。
所以在项目里我直接采用了NavigationBar。如果你用的还是Material 2风格，那用BottomNavigationBar也不算错。不过有一点要提醒：如果项目里设置了useMaterial3: true，却仍然用BottomNavigationBar，有些细节样式会显得不搭。与其后面再来改，不如一开始就统一。
至于自定义底部导航栏，只有两种场景我建议考虑：一是需要在导航栏中间放一个凸起的大按钮，比如随手拍的“+”号；二是视觉效果要完全跳出Material规范，图标、字体、动画全部自定义。自己画导航栏意味着要处理触摸区域、点击反馈、系统导航条避让等一系列问题，代价不小，新手还是先在官方组件上把能力摸透。
3.2 Scaffold + IndexedStack + NavigationBar的核心实现
这一步是整篇博文的重头戏。先看完整代码，再逐个讲解关键点：
import 'package:flutter/material.dart'; import 'pages/home_page.dart'; import 'pages/search_page.dart'; import 'pages/article_page.dart'; import 'pages/mine_page.dart'; void main() { runApp(const GarbageGuideApp()); } class GarbageGuideApp extends StatelessWidget { const GarbageGuideApp({super.key}); @override Widget build(BuildContext context) { return MaterialApp( title: '垃圾分类指南', theme: ThemeData( colorScheme: ColorScheme.fromSeed(seedColor: Colors.green), useMaterial3: true, ), home: const MainTabPage(), ); } } class MainTabPage extends StatefulWidget { const MainTabPage({super.key}); @override State<MainTabPage> createState() => _MainTabPageState(); } class _MainTabPageState extends State<MainTabPage> { int _currentIndex = 0; static const List<Widget> _pages = [ HomePage(), SearchPage(), ArticlePage(), MinePage(), ]; @override Widget build(BuildContext context) { return Scaffold( body: IndexedStack( index: _currentIndex, children: _pages, ), bottomNavigationBar: NavigationBar( selectedIndex: _currentIndex, onDestinationSelected: (index) { setState(() { _currentIndex = index; }); }, destinations: const [ NavigationDestination( icon: Icon(Icons.home_outlined), selectedIcon: Icon(Icons.home), label: '指南', ), NavigationDestination( icon: Icon(Icons.search_outlined), selectedIcon: Icon(Icons.search), label: '查询', ), NavigationDestination( icon: Icon(Icons.article_outlined), selectedIcon: Icon(Icons.article), label: '专题', ), NavigationDestination( icon: Icon(Icons.person_outline), selectedIcon: Icon(Icons.person), label: '我的', ), ], ), ); } }这段代码的核心结构就三件事：用StatefulWidget持有_currentIndex，用IndexedStack承载四个页面，用NavigationBar作为底部导航入口。onDestinationSelected回调里更新索引，触发build，IndexedStack切换到对应页面，整个过程非常直观。
3.3 为什么坚持用IndexedStack而不是直接切页面
这是一个几乎所有Flutter实战都会碰到的问题：Tab切换时，页面状态到底保不保留？
如果简单地在Scaffold的 body 里写_pages[_currentIndex]，看似也能工作，但每次切换Tab都会销毁旧页面、创建新页面。带来的直接后果是：查询页里刚输入一半的搜索词丢了，首页列表滚动到一半的位置回弹了，专题页文章加载的状态也要重新来一遍。这种体验在工具类App里非常劝退。
IndexedStack的解法是把所有子页面都保存在组件树里，通过index控制当前显示哪一个。切换只是改一个索引，页面实例不会销毁，状态天然保留。我在实战里对这个选择深有体会：用户在查询页搜索“电池”，切到首页看一眼分类，再切回查询页，搜索词和结果列表还在，这种细节会让用户觉得App很“跟手”。
不过IndexedStack也不是没有代价。它会在首次构建时把所有子页面都实例化一遍，如果每个页面都在build里做重量级初始化，比如同步解析大JSON、发起网络请求，首帧就会明显变卡。垃圾分类指南这个体量不大，四页面同时构建没什么压力，但你自己做项目时一定要有这个意识，尽量把耗时逻辑延迟到页面真正可见后再执行。
3.4 图标选中态、角标和主题色的细节调整
NavigationBar的NavigationDestination支持分别配置icon和selectedIcon，这是提升底部导航质感最简单的手段。我用的是同一个图标的线性和实心版本，比如首页用Icons.home_outlined表示未选中，选中之后变成Icons.home。没有配置selectedIcon也能工作，默认只靠主题色变化区分选中状态，但有了图标形态的变化，用户对当前Tab的感知会更清楚。
角标是一个很容易被忽略但很实用的功能。比如给查询页加一个Badge，可以提示有新的可识别垃圾类别更新；给“我的”页加角标，可以模拟未读消息。代码就是在NavigationDestination的icon外再套一层：
NavigationDestination( icon: Badge( label: Text('3'), child: Icon(Icons.person_outline), ), selectedIcon: Badge( label: Text('3'), child: Icon(Icons.person), ), label: '我的', )主题色的统一也很关键。我在MaterialApp里用ColorScheme.fromSeed(seedColor: Colors.green)生成了一套绿色系配色，正好贴合垃圾分类的环保氛围。NavigationBar的选中态颜色、图标颜色、指示器样式都会自动跟随这套配色，不用再一个个单独设置。
3.5 二级页面与底部导航的关系
底部导航栏只存在于主页面MainTabPage的Scaffold上，进入二级页面时，我用的是标准的Navigator.push，这样二级页面会从屏幕底部或者侧边滑入，盖住整个主界面包括底部导航栏。为什么要这样设计？因为二级页面是完整的内容页，需要最大的展示空间，同时它们有自己的Scaffold和AppBar，负责提供返回按钮和页面标题。
这个方案有个天然的好处：从详情页返回时，底部导航栏所在的MainTabPage并没有被销毁，各个Tab的状态都还活着。用户从“查询”Tab进入物品详情，看完返回，停留的还是查询页，搜索词原样还在。这种数据流很符合直觉，用户不需要重新找位置。
页面跳传参也在这个环节体现。首页分类卡片点击后，把分类名作为参数传给列表页：
Navigator.push( context, MaterialPageRoute( builder: (_) => CategoryListPage(category: category), ), );然后列表页根据分类名过滤数据，点击物品再进入详情页。这一层导航栈的搭建，是底部导航栏之外整App交互的第二根支柱。
3.6 状态栏、安全区与多设备适配
OpenHarmony设备形态很杂，有手机、平板，还有各种带挖孔或屏下摄像头的屏幕。顶部AppBar一般会自动避让状态栏，但如果你用自定义头部或者沉浸式页面，就要手动处理。最稳的做法就是SafeArea，把内容约束在系统安全区内：
SafeArea( child: ListView(...), )但我不建议在MaterialApp最外层无脑包一个全局SafeArea，那样反而可能在部分页面上出现双重避让，造成无用的空白边距。按页面按需包裹，更可控。
底部导航栏通常由系统自动处理，不跟手势条重叠。但如果页面是全屏沉浸模式，就要用MediaQuery.of(context).viewPadding判断底部安全区域，在内容末尾手动垫高。这个细节在OpenHarmony平板上尤其明显，不同设备的viewPadding数值差异很大，最好在几台不同设备上各跑一遍看看效果。
4. 垃圾分类指南四个页面逐个落地
4.1 数据模型与本地数据组织
页面框架搭好之后，开始填充业务内容。第一步是定义数据模型。垃圾分类的物品需要哪些字段？我的基础设计是名称、分类、描述、处置建议、搜索关键词：
class GarbageItem { final String name; final String category; final String description; final String dispose; final List<String> keywords; const GarbageItem({ required this.name, required this.category, this.description = '', this.dispose = '', this.keywords = const [], }); factory GarbageItem.fromJson(Map<String, dynamic> json) { return GarbageItem( name: json['name'] as String, category: json['category'] as String, description: json['description'] ?? '', dispose: json['dispose'] ?? '', keywords: (json['keywords'] as List<dynamic>? ?? const []).cast<String>(), ); } }数据源放在assets/data/garbage_data.json，在pubspec.yaml里声明：
flutter: assets: - assets/data/garbage_data.json加载时用rootBundle.loadString：
Future<String> loadGarbageData() async { return rootBundle.loadString('assets/data/garbage_data.json'); }数据加载要放在异步方法里，并且用缓存把结果存住，避免每次进入页面都重新解析。一个简单的做法是做一个数据仓库单例，首次加载后把解析结果放在内存里，后续页面直接取。
4.2 首页分类指南：四大分类卡片与列表页
首页展示四大分类卡片。我做的卡片分为标题、分类描述、样例物品三部分，例如可回收垃圾卡片会显示“塑料瓶、报纸、纸箱”等样例词。整页布局用了ListView，每张卡片是独立Widget，点击后跳转到对应分类的物品列表。
分类列表页的逻辑并不复杂：接收分类名参数，从全局数据源里过滤出category匹配的物品，然后用ListView.builder展示。这里一个关键点是要用ListView.builder而不是ListView(children: [...])，因为物品数量可能达到几百个，builder模式按需构建列表项，滚动性能会好很多。列表项点击后进入详情页，展示物品的描述和处置建议。
首页这种卡片式入口的好处是，用户第一眼就能看到四大分类，不需要动脑思考“我该去哪里”，点击路径非常短。对工具类App来说，用户效率就是核心体验。
4.3 查询页：实时搜索与状态保留的实际体验
查询页是垃圾分类指南里最彰显IndexedStack价值的地方。页面结构是一个搜索框加一个结果列表，搜索框的onChanged每次触发都更新查询词，然后对内存里的物品列表做过滤：
TextField( onChanged: (value) => setState(() => query = value), decoration: const InputDecoration( hintText: '输入垃圾名称，比如：废电池', ), )过滤逻辑要覆盖名称、分类、关键词三类匹配：
final results = allItems.where((item) { final q = query.trim().toLowerCase(); if (q.isEmpty) return false; return item.name.toLowerCase().contains(q) || item.category.contains(q) || item.keywords.any((k) => k.toLowerCase().contains(q)); }).toList();搜索结果列表项会显示物品名称和它所属的分类标签，点击进入详情。整个交互做到“边输入边出结果”，体感很直接。
这里我想特别提一下IndexedStack在真实场景中的价值：用户如果在查询页输入了“电池”，临时切到首页去确认某个分类，再切回来，搜索词仍然停在“电池”，结果列表也是刚才的状态。听上去像理所当然，但很多App在类似切换后搜索状态会丢，用户不得不重新输入，这个细节特别影响耐性。
如果以后数据量大，搜索性能不够，可以考虑引入拼音索引和本地搜索缓存。但以垃圾分类这类几千条数据的使用场景，直接内存过滤完全够用，别过早优化。
4.4 专题文章页与个人中心页
专题页的结构是文章列表。文章模型相对简单：id、标题、摘要、正文、发布日期。列表展示标题和摘要，点击进入文章详情页。详情页用SingleChildScrollView加Text渲染，如果后期文章格式变复杂，可以切换到富文本编辑器输出HTML并引入渲染组件。我这个阶段先用纯文本，减少对第三方包的依赖，尤其要避免引入OpenHarmony上不支持的包。
个人中心页我做的是最基础的信息架构：顶部一个简单的用户占位区，下面是功能列表，包括我的收藏、设置、关于。收藏功能先放在内存里，用户点击收藏后记录物品ID，在“我的收藏”页面里展示收藏列表，重启后会清空。要持久化，可以考虑用文件存JSON，或者找一个支持ohos平台的键值存储插件。这里其实牵扯到Flutter for OpenHarmony生态的一个现状：不是所有常用插件都能直接跑，选型之前一定要看目标包有没有ohos平台的实现。
5. 常见问题与避坑记录
5.1 flutter devices识别不到OpenHarmony设备
这是最常遇到的入门问题。现象是IDE里模拟器已经启动，但flutter devices列表里就是没有对应的设备。排查顺序是：先确认IDE插件是否已经安装并且启用了OpenHarmony支持；再确认模拟器本身是否正常启动并进入了系统界面；最后确认Flutter SDK版本和工具链确实支持ohos平台。很多时候问题出在IDE插件没有正确绑定到当前使用的Flutter SDK上，重新配置一下插件路径就能解决。
5.2 依赖包不支持ohos平台
pub.dev上的很多包没有实现OpenHarmony平台，跑起来会直接报编译错误，提示找不到对应平台的实现类。遇到这种问题，我的处理优先级是：先找一个支持ohos的替代包；替代包也没有，看包的核心功能是否依赖原生能力，如果只是纯Dart实现，可以直接把源码复制进项目；如果确实要用原生能力，那要么自己在ohos目录里写PlatformChannel实现，要么改架构绕开这个需求。
我个人的经验是，保持依赖尽可能小。垃圾分类指南项目里能不用第三方包就不用，列表、导航、搜索这些Flutter自带组件都能覆盖。依赖越少，跨平台适配的痛苦就越少。
5.3 日志看不到，print去哪儿了
Flutter在OpenHarmony平台上的标准输出并不总是出现在IDE的控制台。我在调试时最常用的方式是通过Flutter工具自身提供的日志通道确认Dart侧输出，具体就是在IDE里查看系统日志窗口，或者用集成日志工具定位应用进程的日志。这里没有统一的标准答案，不同版本的适配工具日志位置略有不同，但只要形成了“先确认日志去向再开始调试”的习惯，排查问题会少走很多弯路。
另外，热重载在OpenHarmony上也不像Android那么稳定。只改lib目录下的Dart代码，热重载一般有效；一旦改了ohos目录下的原生代码，基本就得重新构建运行。理解了这一点，就不会在原生改动后反复尝试热重载而无果。
5.4 底部导航栏状态与布局问题速查
我把实际开发中碰到的底部导航栏相关问题整理成了速查表，方便后面开发时对照排查。
| 问题现象 | 常见原因 | 解决参考 |
|---|---|---|
| 底部导航被系统手势条遮挡 | 沉浸式页面未处理底部安全区 | 用MediaQuery查看viewPadding并按需垫高 |
| 导航栏在平板上显得太高或太矮 | 默认高度在不同设备上表现不一致 | 根据设备宽度和形态微调NavigationBar样式 |
| Tab切换后页面状态丢失 | body里直接切换页面实例，未用IndexedStack | 改用IndexedStack承载页面 |
| 首次进入App卡顿 | IndexedStack同时构建所有页面 | 页面初始化时避免耗时逻辑，延迟到可见后再加载 |
| 热重载不生效 | 修改了原生ohos目录代码 | 需要重新构建运行 |
| 中文文本溢出或换行异常 | 固定宽度布局，未考虑系统字体缩放 | 合理使用Flexible/Expanded，测试大字体模式 |
6. 后续还能怎么玩：导航栏进阶与App功能扩展
6.1 底部导航栏的进阶玩法
这套基础骨架稳定之后，导航栏可以往几个方向再进阶。一个是中间凸起按钮，比如在NavigationBar上方叠加一个悬浮按钮，通过Stack把按钮定位在导航栏中间偏上的位置，点击后弹出拍照识别页面，这种结构在工具类App里很常见。另一个是Tab切换动画，可以用AnimatedSwitcher包装body区域，让页面切换时带有淡入淡出或滑动效果，视觉反馈更明显。还有就是引入状态管理，把_currentIndex抽到全局状态里，这样页面内某个操作也可以主动跳转到其他Tab，比如“我的”页面点击某个入口后自动切回首页，这种跨页面联动靠setState自己做会很别扭，用状态管理库会省心很多。
6.2 垃圾分类App本身的可扩展方向
垃圾分类指南这个App的业务边界其实是开放的。数据层面可以接后端接口，让分类规则和物品库支持远程更新；功能层面可以加拍照识别，调用图像分类模型判断垃圾类别；场景层面可以做附近回收点地图展示和积分任务体系。每个方向都能单独拆成一篇实战文章。但这个阶段最重要的还是把基础框架打牢，导航稳定、状态保持、数据分层清晰，这些都是后面所有扩展的地基。
我在实际开发中收获最大的不是最终App多好看，而是理解了“为什么底部导航栏要这样搭”：IndexedStack解决状态问题，独立Scaffold解决页面栈问题，按需SafeArea解决设备适配问题。这些选择都不是拍脑袋决定的，而是对应着真实使用场景里的用户尴尬。希望这篇记录能帮你少踩几个坑，顺利跑通你自己的Flutter for OpenHarmony实战项目。
