企业官网建设流程全解析

把垃圾分类指南做成App，最核心的诉求其实不复杂：用户想知道手里的东西属于哪类垃圾。但真上手做的时候你会发现，用户每天查的东西大部分是重复的，今天查“电池”，明天还要查“电池”，就连“奶茶杯”这种词一周能出现五六次。所以搜索历史这个看起来不起眼的功能，恰恰是高频路径里最值得认真做的模块之一。

这个项目是在OpenHarmony设备上用Flutter开发垃圾分类指南App，搜索历史实现看似简单，但牵扯到数据存储、状态管理、原生通道协作、键盘交互、列表性能等多个层面。而且Flutter跑在OpenHarmony上不是简单的“能跑就行”，很多在Android/iOS上顺手的方案到了鸿蒙平台会有自己的脾气。这篇文章把我实际做这个功能时踩过的坑、验证过的写法、最后沉淀下来的实现方案完整记录下来，适合正在用Flutter适配OpenHarmony的开发者参考，也适合刚把Flutter环境搭起来、准备做第一个完整功能的新手抄作业。

1. 项目定位：垃圾分类指南的搜索历史到底在解决什么问题

1.1 搜索历史不是“记录”，是“复访路径”

很多开发者在做App时会把搜索历史当成一个日志系统，往本地存一堆字符串就完事。但其实搜索历史在产品层面承担的是“复访路径”的角色，用户不需要重新输入完整关键词，点一下标签就能回到上次查过的内容。垃圾分类App尤其特殊，用户查询的对象往往是自己不太确定的东西，比如“瓜子壳”“大棒骨”“榴莲壳”，这类词不常见但会反复出现，而且用户下次根本想不起来自己上次是怎么查的。

所以搜索历史的本质不是存储，而是让用户以最低成本重新找到曾经的信息。顺着这个思路，产品逻辑就很清晰：重复查询的词要排在前面、最新查询的要排在最前面、支持一键清空、点击历史词要直接触发搜索而不是只填入输入框。这些细节直接影响用户对App“好不好用”的感知。

1.2 技术选型：Flutter + OpenHarmony 组合的合理性

选择Flutter来开发OpenHarmony应用，很大原因是团队已经熟悉Dart和Flutter组件体系，而且Flutter社区对OpenHarmony的适配越来越成熟。相对于ArkTS原生开发，Flutter能保留跨端复用的优势，UI表现力也足够支撑垃圾分类这种偏工具类的应用。

不过要清醒认识到，Flutter for OpenHarmony和Flutter for Android之间不是完全无缝的。最明显的差异体现在两处：一是底层存储和系统服务需要通过平台通道去对接，二是OC渲染层的适配在部分低端鸿蒙设备上还有性能损耗。搜索历史这种功能并没有依赖复杂原生能力，用纯Flutter侧方案就能覆盖，这反而让整个模块的实现风险降到最低。我的建议是：在OpenHarmony上跑Flutter，凡是能用纯Dart解决的问题，尽量不要去碰原生通道，通道通信带来的调试成本远比你想象的高。

1.3 搜索历史模块的整体拆解

我把整个搜索历史功能拆成四个子问题：数据怎么存、状态怎么管、UI怎么交互、异常怎么处理。数据层解决记录的增删改查；状态层解决页面重建后历史数据不丢失；交互层解决搜索框的输入、历史标签的点击回填、清空确认；异常层解决键盘遮挡、重复插入、SDK版本兼容这类实际运行中的问题。

这四个问题正好对应下面的四个核心章节，每个部分我都会给出完整的代码和设计理由，而不是只贴一段代码让你自己猜。

2. 数据层设计：从一条搜索记录到完整的历史列表

2.1 SearchRecord 数据模型与JSON序列化

搜索历史最基础的数据结构是一条记录，我建议不要只存一个字符串，至少包含关键词和查询时间两个字段。为什么要有时间字段？因为历史列表需要按时间排序，还要支持“今天”“昨天”“更早”这种分组展示，只有keyword的话后期做这些功能就得重构存储结构。

class SearchRecord { final String keyword; final int timestamp; final String dateText; const SearchRecord({ required this.keyword, required this.timestamp, required this.dateText, }); Map<String, dynamic> toJson() => { 'keyword': keyword, 'timestamp': timestamp, 'dateText': dateText, }; factory SearchRecord.fromJson(Map<String, dynamic> map) => SearchRecord( keyword: map['keyword'] as String, timestamp: map['timestamp'] as int, dateText: map['dateText'] as String, ); }

这里有个容易忽略的点：dateText是用“今天”“昨天”这种可读字符串还是用yyyy-MM-dd格式。我建议存储时用标准日期格式，展示时再转换成“今天”“昨天”。因为dateText一旦存储成“今天”，第二天打开App就会变成错误的日期标签，这种脏数据很难清理。我的做法是存储日期格式，在展示分组时动态计算相对时间。

提到序列化，还有一个Flutter里常见的坑：不要直接用jsonEncode去处理带中文的记录，不是中文本身有问题，而是确保你和前端、数据库之间统一用UTF-8编码。在OpenHarmony设备上有些老版本的系统文件读写默认字符集不一致，最容易出现的就是中文乱码。凡是跨通道的数据，我都会显式声明utf8，不让平台自己去猜。

2.2 存储方案对比：shared_preferences还是sqflite

搜索历史数据量不大，单机几十条记录而已，很多教程会直接推荐shared_preferences。我的实际体验是：如果只是存一个String列表，shared_preferences确实够用，但一旦涉及排序、去重、分组查询，纯字符串数组会让你写出大量临时逻辑，而且每次增删都要全量重写，稍微一个并发操作就把数据搞乱。

更稳的方案是sqflite，它本身就是Flutter生态里最常用的SQLite插件，在OpenHarmony上也有对应的适配版本。搜索历史这种适合用数据库表存储，甚至不需要ORM，一个简单的表结构加几个SQL语句就能干净地解决所有问题。

综合考虑，我最终选了sqflite。建表语句如下：

CREATE TABLE search_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, keyword TEXT NOT NULL, timestamp INTEGER NOT NULL ); CREATE INDEX idx_records_timestamp ON search_records(timestamp DESC);

注意索引那个语句，很多新手会漏掉。搜索历史每次进入页面都要按时间倒序查一次，没有索引在数据量小的时候感觉不出来，一旦用户积攒了大半年记录，查询延迟就会明显拖慢页面加载。加一个timestamp索引，成本几乎为零，收益是长期的。

2.3 去重、上限、时间分组，三个最容易被忽略的规则

搜索历史的三个核心规则，缺一个体验就会打折。第一个是去重：同一个关键词只保留最后一次查询时间，重复查询应该把它更新到最前面。注意去重的比较逻辑，除了精确匹配，还应该做trim和大小写归一化。垃圾分类场景下用户可能输入“电池”也可能输入“ 电池 ”，还可能输入“Battery”，这些同一性比较必须在写入前处理掉。

Future<void> addRecord(String keyword) async { final normalized = keyword.trim().toLowerCase(); if (normalized.isEmpty) return; final db = await _getDatabase(); await db.transaction((txn) async { await txn.delete( 'search_records', where: 'LOWER(TRIM(keyword)) = ?', whereArgs: [normalized], ); await txn.insert('search_records', { 'keyword': keyword.trim(), 'timestamp': DateTime.now().millisecondsSinceEpoch, }); }); }

第二个是上限控制，搜索历史不能无限增长。我做了30条上限，超过部分自动删掉最老的。这不是拍脑袋定的：垃圾分类App的查询词数量级有限，30条足够覆盖绝大多数用户的复访需求，同时保持历史区域在页面上的体感不会太长。清理语句很简单：

DELETE FROM search_records WHERE id NOT IN ( SELECT id FROM search_records ORDER BY timestamp DESC LIMIT 30 );

第三是时间分组。列表展示时分“今天”“昨天”“近7天”“更早”四个维度，用户扫一眼就知道哪些是最近查的。分组逻辑放在数据层完成，UI层只负责渲染结果，不要等到UI层再做时间计算。

Map<String, List<SearchRecord>> groupByDate(List<SearchRecord> records) { final now = DateTime.now(); final today = DateTime(now.year, now.month, now.day); final grouped = <String, List<SearchRecord>>{}; for (final record in records) { final day = DateTime.fromMillisecondsSinceEpoch(record.timestamp); final diff = today.difference(DateTime(day.year, day.month, day.day)).inDays; String label; if (diff == 0) { label = '今天'; } else if (diff == 1) { label = '昨天'; } else if (diff < 7) { label = '$diff天前'; } else { label = '更早'; } grouped.putIfAbsent(label, () => []).add(record); } return grouped; }

注意：去重时如果同一关键词在短时间内被重复查询，建议加一个最短间隔限制（比如1分钟内不重复更新），避免用户手滑连点搜索按钮导致历史记录排序异常。

3. 状态管理：搜索历史为什么适合Cubit

3.1 setState方案为什么容易翻车

搜索历史的UI状态天然是跨页面的。用户进入搜索页看到历史列表，点击历史词触发搜索跳转结果页，返回搜索页后历史列表可能已经更新。用传统setState方案时，数据散落在页面State里，页面被Navigator压栈或销毁再重建就会丢失状态更新，这也是很多人在Flutter里遇到的经典问题——Navigator切换页面后为什么会丢状态。

根因是页面Widget销毁后State不复存在，你必须把数据提升到页面生命周期之外的地方保存。最轻量的做法是用ChangeNotifier或者Provider，稍微结构化一点就是用Bloc或Cubit。搜索历史这个模块的状态流很简单：加载历史、新增历史、删除历史、清空历史，没有复杂的业务事件链，不需要引入完整的Bloc事件机制，Cubit正好是这个场景的最佳平衡点。

3.2 SearchHistoryCubit的完整实现

我用flutter_bloc库里的Cubit来做历史模块的状态管理。一个Cubit负责向UI层暴露状态，UI层通过context.read触发方法，通过BlocBuilder监听状态变化重建视图。

class SearchHistoryCubit extends Cubit<SearchHistoryState> { final SearchHistoryRepository _repository; SearchHistoryCubit(this._repository) : super(const SearchHistoryState.initial()); Future<void> load() async { final records = await _repository.getAll(); emit(state.copyWith( records: records, grouped: groupByDate(records), status: SearchHistoryStatus.loaded, )); } Future<void> add(String keyword) async { final normalized = keyword.trim(); if (normalized.isEmpty) return; await _repository.add(normalized); final records = await _repository.getAll(); emit(state.copyWith( records: records, grouped: groupByDate(records), )); } Future<void> remove(String keyword) async { await _repository.remove(keyword); final records = await _repository.getAll(); emit(state.copyWith( records: records, grouped: groupByDate(records), )); } Future<void> clear() async { await _repository.clear(); emit(state.copyWith( records: [], grouped: {}, )); } }

状态类用不可变设计，每次变更返回新的对象。这里有个细节：code里面每次add和remove之后都要重新getAll一次，是因为数据库里的timestamp会被更新，内存里的记录列表如果不刷新就无法反映最新的排序结果。虽然多一次查询，但保证了数据一致性，这点开销在几十条记录的规模下完全可以接受。

class SearchHistoryState { final List<SearchRecord> records; final Map<String, List<SearchRecord>> grouped; final SearchHistoryStatus status; const SearchHistoryState({ this.records = const [], this.grouped = const {}, this.status = SearchHistoryStatus.initial, }); SearchHistoryState copyWith({ List<SearchRecord>? records, Map<String, List<SearchRecord>>? grouped, SearchHistoryStatus? status, }) { return SearchHistoryState( records: records ?? this.records, grouped: grouped ?? this.grouped, status: status ?? this.status, ); } }

3.3 事件到状态的流转，以及和Navigator状态保持的关系

使用Cubit之后，页面的状态保持问题就自然解决了。搜索页从Navigator栈顶被结果页覆盖，只是Widget树里被隐藏，View层依然存在，Cubit实例挂在Provider或者BlocProvider之上，不会随页面销毁，等用户返回搜索页时，BlocBuilder直接读取最新的Cubit状态，历史列表就是最新的。

这里推荐把SearchHistoryCubit用BlocProvider放到搜索页的父级，或者直接放在全局App层。我的选择是放在搜索页所在的Navigator分支上方，这样既保证页面存活周期内Cubit唯一，又不会让历史数据在App整体启动时就去加载。

还有一个和组件通信相关的问题：分类TabBar和搜索历史之间会有联动。用户在上方TabBar切换“可回收物”“有害垃圾”“厨余垃圾”“其他垃圾”，搜索结果和推荐词会变化，搜索历史的展示可能也会因为分类上下文而改变展示优先级。这种场景下Cubit同样是理想的通信工具，TabBar切分类触发Cubit方法，历史列表监听状态变化重新渲染，两个模块之间完全不直接互持引用。

4. 功能闭环：搜索框、历史标签、清空确认的完整实现

4.1 搜索框的交互细节

搜索框是整个搜索历史的入口，交互细节决定了数据能不能正确写入。我用的TextField配置有几个关键点：键盘设置成search动作，方便用户输入完直接点搜索；提交时判断trim后是否为空；输入过程中不在本地写入历史记录，只有真正的搜索动作发生时才写入。

TextField( controller: _searchController, textInputAction: TextInputAction.search, autofocus: false, onSubmitted: (value) { final keyword = value.trim(); if (keyword.isEmpty) return; context.read<SearchHistoryCubit>().add(keyword); _performSearch(keyword); }, decoration: InputDecoration( hintText: '搜索垃圾名称，试试“电池”“奶茶杯”', prefixIcon: const Icon(Icons.search), suffixIcon: _searchController.text.isEmpty ? null : IconButton( icon: const Icon(Icons.clear), onPressed: _searchController.clear, ), ), )

注意那个suffixIcon的清除按钮，很多App会漏掉。用户输错词的时候如果找不到清除按钮，只能全选删除，体验很割裂。我在实际项目中见过不少用户因为输入框没有清空按钮，直接不搜索了，改去别的App看知识科普，这个细节直接影响留存。

还有个实用技巧是给搜索输入加防抖。不是防抖提交搜索，而是防抖实时联想。用户每敲一个字就去数据库里做一次LIKE '%keyword%'查询，在高频输入时会触发大量数据库操作，在低端设备上能明显感觉到卡顿。我的做法是输入监听里加300ms的Timer，用户停止输入后才发起联想查询。

4.2 历史标签的点击回填

历史记录最常见的展示形态是标签云，我用的是Wrap加ActionChip的组合。每个标签带一个历史图标，点击之后自动把标签文本填回搜索框，并且立即触发搜索，因为用户点击历史词的目的就是重新查看结果，不需要二次确认。

Wrap( spacing: 8, runSpacing: 8, children: records.take(10).map((record) { return ActionChip( avatar: const Icon(Icons.history, size: 16), label: Text(record.keyword), onPressed: () { _searchController.text = record.keyword; _searchController.selection = TextSelection.collapsed( offset: record.keyword.length, ); context.read<SearchHistoryCubit>().add(record.keyword); _performSearch(record.keyword); }, ); }).toList(), )

点击历史词时注意两点。第一是重新调用add方法，把该词的时间戳更新到最前面，保证它下次还在前面位置。第二是光标位置要设置到文本末尾，否则用户如果想继续编辑这个词，光标还停在开头，输入内容会插到前面，看起来很怪。

分组展示的时候，一个分组标题对应一个列表，如果列表项多了，最好用缩略列表折叠起来。我在今天的分组下显示全部记录，昨天和更早的分组默认折叠成一行，只显示前3个，展开按钮再做完整展示。用户在搜索页的主要精力是“快速找到上次的词”，折叠策略能降低信息噪音。

4.3 清空历史的二次确认

清空搜索历史是破坏性操作，一定要加二次确认。实际测试里，用户误触清空按钮的概率不低，尤其是这个按钮通常放在页面角落，和删除某个单条记录的按钮挨得近。一条误删还有挽回余地，清空所有历史之后如果还要恢复，就需要引入回收站机制，成本太高，不如在确认这一步拦住。

showDialog<void>( context: context, builder: (context) => AlertDialog( title: const Text('清空搜索历史？'), content: const Text('删除后将无法恢复，确定要继续吗？'), actions: [ TextButton( onPressed: () => Navigator.pop(context, false), child: const Text('取消'), ), TextButton( onPressed: () => Navigator.pop(context, true), child: const Text('清空'), ), ], ), ).then((confirmed) { if (confirmed == true) { context.read<SearchHistoryCubit>().clear(); } });

这里有一个异步回调的细节能顺便讲一下。showDialog返回的Future在对话框关闭时才会完成，如果你在这个then回调里继续执行数据库写入逻辑，注意Flutter事件循环中Future的then回调默认被推入微任务队列，不会执行在对话框动画完成之前。这意味着你不需要额外等待动画结束才弹toast，微任务队列会保证顺序正确。

4.4 空状态与数据统计

搜索历史为空时，页面不能只显示一个空白区域。我做的空状态是一个居中的图标加提示文案，文案写的是“还没有搜索记录，去查一查垃圾分类吧”，底部配上几个推荐种子词，用户不用输入也能快速开始使用。这个推荐词列表不是硬编码的，而是从后台配置拉取，本地缓存，保证分类变化时推荐词能跟随更新。

页面底部我加了一行小字统计：“共X条搜索记录”，同时提供清空按钮。统计信息用BlocBuilder监听Cubit状态随时刷新，比在页面initState时读一次数据库要准确得多。用户一边搜索一边切回来，统计数字也会自动变化，这种动态反馈让整个模块看起来是“活”的。

5. 原生侧协作：什么功能该走通道，什么功能不该走

5.1 MethodChannel和EventChannel的边界

搜索历史在纯Flutter侧都能解决，不需要依赖OpenHarmony原生能力。但如果你想把历史记录和系统账号体系打通，或者未来做跨设备同步，就必须走原生通道。我用OpenHarmony做适配时，MethodChannel和EventChannel的使用场景要分清楚：MethodChannel适合一次请求一次响应的同步操作，比如调用原生接口保存一条记录、读取系统设置；EventChannel适合原生侧主动推送数据，比如系统清理内存时通知Flutter侧同步清理历史、账户切换后从服务端拉回历史列表并通知UI刷新。

static const _methodChannel = MethodChannel('com.example.garbage/search_history'); Future<void> syncHistoryToCloud() async { try { await _methodChannel.invokeMethod('syncHistory', { 'records': jsonEncode(records), }); } on PlatformException catch (e) { debugPrint('同步失败: ${e.message}'); } }

EventChannel这边，我在App启动时注册监听，原生侧任何数据变化都通过广播流推过来：

const _eventChannel = EventChannel('com.example.garbage/history_events'); void listenNativeEvents() { _eventChannel.receiveBroadcastStream().listen((event) { if (event == 'historyCleared') { context.read<SearchHistoryCubit>().load(); } }); }

在OpenHarmony上做MethodChannel适配时，我最大的心得是：先把错误流程测好再上线。鸿蒙的通道调用失败时返回PlatformException，很多时候是原生侧方法名拼写不一致或者参数类型不匹配。我在开发阶段经常遇到Dart侧传过去的是int，原生侧拿到的是double，这类类型不匹配在Android上会因为类型转换直接崩溃，在OpenHarmony上变成静默失败，排查起来更费劲。

5.2 Impeller与PlatformView在OHOS上的取与舍

Flutter on OpenHarmony的适配版本中，Impeller渲染引擎的可用性越来越成熟。搜索历史页面里用到的Widget基本都是文本、图标、Wrap、ListView，Impeller渲染的优势主要体现在大量图形动画和复杂列表滚动的时候。如果你发现历史列表在设备上滚动掉帧，先别急着优化业务代码，检查一下当前使用的Flutter适配版本是否启用了Impeller。在真机上实测下来，启用Impeller后列表滚动帧率有肉眼可见的提升，尤其是历史记录超过20条、页面还有分类TabBar和推荐区同时滚动的时候。

PlatformView则是完全相反的取舍。搜索页如果要嵌入原生组件，比如识别垃圾种类的摄像头预览或者回收站地图，就得用PlatformView。但PlatformView在OpenHarmony上的混合渲染链路比Android长，嵌入后会引入输入事件穿透、滚动同步这些问题。能不用尽量不用，如果确实要嵌入原生Scanner或Map，我建议把PlatformView隔离到独立的页面，不要让历史列表和PlatformView在同一屏滚动，否则滑动历史的图层共享会造成严重掉帧。

5.3 判断哪些原生能力真的和你相关

OpenHarmony的HDI（硬件设备接口）是很底层的硬件抽象能力，做搜索历史根本用不到。但我在团队评审时经常看到有人犯一个错：一提到OpenHarmony适配，就想着把能力都往HDI上靠，仿佛用上原生接口才显得完整。事实恰恰相反，搜索历史这种轻量数据模块，在Flutter侧的sqflite加Cubit已经是最优解。

真正和原生侧相关的场景只有三个：第一，需要统一输入法行为，在部分鸿蒙设备上的第三方输入法对TextField的兼容性参差不齐，某些皮肤键盘和Flutter文本输入框的焦点管理冲突，这里可能需要原生侧调整输入法配置；第二，跨进程数据同步，比如Widget卡片也显示最近搜索的词，需要原生侧提供存储读取；第三，系统回收优化，鸿蒙系统在内存压力下可能清理应用进程，如果搜索历史没有及时落盘，就会被系统回收，这里需要确保数据库写入时机及时，和原生侧的进程管理无关。判断清楚了，开发时就不会为了“融入平台”而盲目加原生依赖。

6. 实战中的问题与排查技巧实录

6.1 搜索框键盘遮挡历史列表

这是搜索历史页面最经典的问题，没有之一。用户点击搜索框弹起键盘后，键盘会直接盖住下半屏的历史标签。最开始我用的是Scaffold的默认行为，期望resizeToAvoidBottomInset自动处理，实际在鸿蒙设备上有时不生效，原因在于部分设备的系统导航栏模式和输入法高度计算方式不同。

我的处理方案比较直接：用WidgetsBindingObserver监听键盘高度变化，把历史列表的主区域通过Padding抬起来，高度等于MediaQuery.of(context).viewInsets.bottom。同时给ListView加上clipBehavior: Clip.none，避免键盘弹起时列表内容被裁剪掉一块。

bottom: Padding( padding: EdgeInsets.only( bottom: MediaQuery.of(context).viewInsets.bottom, ), child: const SearchHistoryList(), ),

这里还要配合滚动定位。用户输入过程中，当前输入光标对应的候选词可能被键盘挡住，我用Scrollable.ensureVisible把当前焦点项滚进可视区域，比手动计算偏移量省事很多。

6.2 重复插入和大小写混乱

搜索历史出现重复词是开发中第一个容易被用户发现的bug。我排查过一条很有意思的复现路径：用户输入“电池”，搜完返回，输入法词条里自动记忆了“电池”，第二次点击输入法候选词直接触发onSubmitted，结果因为接收到的值和原记录完全一致，去重逻辑判定为重复，正常应该更新timestamp排到最前。但问题出在大小写混用：用户第一次输“Battery”，第二次输“battery”，如果不做大小写归一化，就会存进两条记录，占用有限的历史名额。

解决方法是写入前统一处理，大小写归一化用toLowerCase，首字母大写的语义在历史标签里弱化，不影响用户识别。关键词前后空格一定要trim，这看起来微不足道，但它的影响是输“电池”和“电池 ”存成了两条，用户看到历史列表里两个一模一样的词，信任感瞬间就没了。

6.3 Flutter SDK版本导致的构建报错

做OpenHarmony适配时最常遇到的构建问题是那句“The current configured Flutter SDK is not known to be fully supported. Please...”。这个报错本质是Flutter SDK版本和OpenHarmony适配插件版本不匹配。我遇到过一次，本地明明装的是最新版Flutter，但跑鸿蒙设备构建时却提示SDK不受支持。排查下来是OHOS的插件包版本只适配到某个固定的Flutter版本，新版Flutter改了内部接口签名，插件校验就炸了。

注意：Flutter和OpenHarmony适配层的依赖关系要锁定版本。不要盲目升级Flutter SDK，也不要盲目升级插件，三者的版本矩阵要一起对齐。

和这个问题相关的还有编译打包时Java层断言错误，比如java.lang.AssertionError，这类报错绝大多数也是SDK和插件版本错位导致，而不是代码问题。解决方法是把Flutter版本降到适配插件支持的版本范围，或者反过来把插件升级到适配新版Flutter的版本，不要在报错信息里纠结太久。

6.4 列表卡顿和TabBar点击取消动画

搜索历史记录多起来之后，我发现一个性能隐患：每次新增记录，Cubit都会重建整个分组Map，然后BlocBuilder把整个Wrap列表全部重新绘制。在记录少于30条时感觉不出来，但加上分类TabBar切换、推荐词区域刷新，低端鸿蒙设备偶尔会出现肉眼可见的卡顿。

优化办法是用BlocSelector拆细监听粒度，而不是整个页面都监听Cubit状态。历史列表区域单独监听records变化，推荐词区域单独监听推荐列表数据，两边的setState不再互相牵连。另外给历史标签的Wrap加一个const构造标识，让Flutter在Widget重建时跳过未变化的子Widget，这个在渲染层能省不少重建开销。

TabBar点击取消动画这个需求，在搜索结果页的“可回收物/有害垃圾/厨余垃圾/其他垃圾”分类切换中很常见。默认TabBar每次点击都播放指示器动画，用户如果快速切换多个分类，动画就会排队执行，看起来非常拖沓。去掉动画的方式是设置TabBar的animationDuration: Duration.zero，同时配合TabBarView的physics参数调整滑动跟随行为。这个细节和搜索历史本身没有直接关系，但它影响了整个搜索体验的连贯性，值得一并优化。

6.5 问题排查速查表

最后把上面这些问题整理成一张速查表，开发时直接对照排查，能帮你省下大量重复调试时间。

最后再分享一个小技巧

搜索历史模块做完之后，我给这个功能加了一个“冷启动预加载”的优化。用户打开App进入首页，首页底部就有搜索入口，这时候我提前把历史数据加载到Cubit里，等用户真正进入搜索页时，历史列表已经渲染完成，完全不需要等待数据库查询。虽然单次查询也就几十毫秒，但页面切换时少一个loading闪烁，体感会明显更顺畅。

另外我在这个项目里最大的体会是，OpenHarmony上跑Flutter时，很多通用方案都会因为平台差异冒出来小问题，但不要一遇到问题就怀疑是适配不成熟。绝大多数情况下，问题根源还是Flutter侧的知识掌握得不够深。搜索历史是个很小的模块，但它把存储、状态、UI、性能、平台兼容这几个层次都串到了，把这一个功能做扎实，你对Flutter在OpenHarmony上的整体理解会上一个台阶。