企业官网建设流程全解析

1. 垃圾细分场景下的搜索历史：这块需求比想象中复杂

先交代一下背景。我最近在做一款面向居民的垃圾分类指南App，目标是让用户输入垃圾名称就能查到正确的投放类别。技术栈选了Flutter，并针对OpenHarmony（开源鸿蒙）平台做了适配。项目推进到第二周时，需求文档里出现了一条看似不起眼的任务——“实现搜索历史功能”。当时我内心是有点不以为然的，觉得不就是把用户搜过的词存起来再展示出来嘛，能有多复杂？真动手之后才发现，这条需求背后牵扯出的一系列问题——数据存哪里、怎么去重、何时清除、多页面怎么同步、组件之间怎么通信——几乎把Flutter for OpenHarmony开发中容易踩的坑都趟了一遍。

先说清楚“搜索历史”在这个App里到底承担什么职责。垃圾分类查询是一个典型的“高频复访”场景，很多用户今天搜“过期药品”、明天搜“废旧灯管”，同一个物品可能因为家庭整理或换季反复出现。搜索历史不是锦上添花，而是直接降低用户重复输入成本的关键功能。从我方产品侧给到的数据来看，接入搜索历史后，用户日均搜索次数提升了大约18%，这个功能甚至能直接影响App的留存指标。

但正是这种“看起来简单、实际上涉及面广”的功能，最容易在小项目里被低估。搜索历史至少涉及四条链路：输入过程中的实时记录、结果页的回填联动、历史列表的展示与删除、以及跨页面甚至跨进程的数据同步。如果只想“先跑通再优化”，后期会非常被动。我在OpenHarmony的DevEco Studio环境里调试时，甚至遇到过历史记录写入了但UI不刷新的诡异问题，排查了半天才发现是既有Flutter组件通信方案与OpenHarmony的布局更新机制存在冲突。

这篇文章不准备从头讲一遍垃圾分类指南App的完整开发过程，那样太散。我重点把“搜索历史”从需求拆解、数据设计、UI实现、组件通信到OpenHarmony适配的全部实战过程写出来，附上可运行的代码片段和踩坑记录。如果你正在做Flutter跨端应用，尤其是目标平台里有OpenHarmony的，这篇文章应该能帮你节省不少试错时间。

2. 搜索历史的核心需求拆解：不只是“存下来再显示”

动手写代码之前，我习惯先画一张需求表格，把搜索历史所有可能的行为路径列出来，然后逐条确认哪些做、哪些不做、哪些留到二期。这一步看起来费时间，但对后续的数据结构设计影响极大。

2.1 功能行为清单与边界确认

我和产品经理对齐后，最终确认了以下行为规则：

• 用户提交搜索后，关键词自动存入历史记录。
• 同一关键词在短时间内重复搜索，不新增记录，只更新时间戳并移动到最前。
• 历史记录最多保留20条，超出后自动淘汰最旧一条。
• 用户可以通过单项删除按钮移除某条记录，也可以一键清空全部。
• 用户点击历史记录中的某个词条，直接触发搜索并回填搜索框。
• 搜索历史在搜索页退出后再次进入仍然存在，App重启后仍然存在。

很多人容易漏掉的是“短时间”这个限定条件。如果不加任何限制，用户反复搜同一个词时，历史列表的顺序会不断变化，视觉上看起来像在“跳动”。我当时的处理方案是加了一个两小时的去重窗口：两小时内重复搜同一词只更新时间戳不进新记录，超过两小时再搜同一词则视为一次全新的搜索。

2.2 数据存储的技术选型分析

搜索历史的数据量不大（最多20条，每条几十字节），但对读写频率有要求。在Flutter for OpenHarmony的场景下，存储方案我评估过三种：

最终我选了shared_preferences，理由是搜索历史的数据形态非常简单，就是“一组按时间排序的字符串及其时间戳”，完全不需要SQL这种重型武器。OpenHarmony的沙箱机制和Android类似，shared_preferences插件在HarmonyOS NEXT的Flutter适配层已经有了可用实现，我实测在OpenAtom开源的flutter_flutter仓基础上编译的版本可以正常读写。

一个大原则：存储方案的选择依据是数据复杂度与访问模式的匹配度，而不是方案本身的热度。别看某个数据库插件在社区里讨论多就拿来用，20条字符串数据用数据库是杀鸡用牛刀，还会白白增加二进制体积和初始化耗时。

2.3 数据模型设计：一条历史记录到底该存什么

很多人做搜索历史只存一个字符串数组，弊端很快会在功能迭代时暴露，比如以后要支持“搜索热词分类展示”或“按日期分组查看”。我定义了一个轻量模型：

class SearchRecord { final String keyword; final int timestamp; // 毫秒级时间戳 final int searchCount; // 同一关键词累计搜索次数 SearchRecord({ required this.keyword, required this.timestamp, this.searchCount = 1, }); Map<String, dynamic> toJson() => { 'keyword': keyword, 'timestamp': timestamp, 'searchCount': searchCount, }; factory SearchRecord.fromJson(Map<String, dynamic> json) => SearchRecord( keyword: json['keyword'] as String, timestamp: json['timestamp'] as int, searchCount: json['searchCount'] as int? ?? 1, ); }

searchCount这个字段是我主动加的，产品需求里并没有。加它的原因是我判断二期很可能需要做一个“热搜榜”，而热搜榜的本质就是按累计搜索次数排序。预先在数据结构里留好位置，比以后做数据迁移省事得多。shared_preferences本质上就是一条JSON字符串，所以我直接把List<SearchRecord>序列化成JSON数组后整体存储：

class SearchHistoryManager { static const String _storageKey = 'search_history_records_v1'; static const int _maxRecords = 20; static const Duration _deduplicationWindow = Duration(hours: 2); final SharedPreferences _prefs; SearchHistoryManager(this._prefs); Future<List<SearchRecord>> loadRecords() async { final raw = _prefs.getString(_storageKey); if (raw == null || raw.isEmpty) { return []; } try { final list = json.decode(raw) as List<dynamic>; return list .map((e) => SearchRecord.fromJson(e as Map<String, dynamic>)) .toList(); } catch (e) { // 数据损坏时兜底：清空重来 await _prefs.remove(_storageKey); return []; } } Future<void> addRecord(String keyword) async { final records = await loadRecords(); final normalized = keyword.trim(); if (normalized.isEmpty) { return; } final now = DateTime.now().millisecondsSinceEpoch; final existingIndex = records.indexWhere((r) => r.keyword == normalized); if (existingIndex != -1) { final existing = records[existingIndex]; final delta = now - existing.timestamp; if (delta < _deduplicationWindow.inMilliseconds) { // 短时间重复，只更新时间戳并前移 records.removeAt(existingIndex); records.insert(0, SearchRecord( keyword: normalized, timestamp: now, searchCount: existing.searchCount, )); } else { // 超过窗口期，视为新搜索 existing.searchCount++; records.removeAt(existingIndex); records.insert(0, existing); // 注意这里要重新设置timestamp，实际需要在insert前更新 } } else { records.insert(0, SearchRecord(keyword: normalized, timestamp: now)); } final trimmed = records.take(_maxRecords).toList(); await _prefs.setString(_storageKey, json.encode( trimmed.map((e) => e.toJson()).toList(), )); } }

写完这段代码后我自己review了一遍，发现两个问题：一是在“超过窗口期重复搜索”的分支里只增加了searchCount，没有更新时间戳；二是timeDelta的判断应该包含等于场景。这些都是细节，但细节正是这类功能最容易出bug的地方。修正后的版本我放在后面的完整实现章节里，这里不展开。

3. 搜索历史的数据管理模块：封装、读写与容错

需求拆解完成后，下一步就是搭建数据管理模块。搜索历史的存储读写逻辑完全独立于UI，因此我把它封装成一个单例管理器，界面层只调用接口，不直接操作SharedPreferences。这个设计一开始看起来有些过度，但后来调试OpenHarmony上的竞态问题时，这个封装帮了大忙。

3.1 单例管理与读写时序问题

SharedPreferences的读写是异步的，如果在极短时间内连续调用addRecord，很可能出现后一次读取还没拿到前一次写入结果的情况。我在模拟器上测试时，手指快速连续提交三次搜索，历史记录最终只出现两条甚至一条。根本原因就是读-修改-写这个序列不是原子操作。

解决思路有几种：最简单的是在管理器内部加一个互斥标记。由于Dart是单线程模型（不考虑isolate），在普通异步方法中只需要防住“协程交错”即可。我用的方案是在写入期间将后续写入请求排队，用一个Future链串行化：

Future<void> _pendingWrite = Future.value(); Future<void> addRecord(String keyword) { final completer = Completer<void>(); _pendingWrite = _pendingWrite.then((_) async { try { await _addRecordInternal(keyword); completer.complete(); } catch (e, stack) { completer.completeError(e, stack); } }); return completer.future; }

这样无论外面如何并发调用，实际写入动作都是串行的。OpenHarmony的Flutter运行时对异步任务调度的行为与标准Flutter基本一致，这个方案在真机上验证过，连续提交10次搜索没有丢记录。这个“Future链作为轻量级互斥锁”的技巧，在处理本地存储竞态时非常实用。

3.2 损坏数据处理与降级策略

OpenHarmony的沙箱存储偶发出现异常时，SharedPreferences的读取结果可能是半截JSON（比如App进程被系统在写入中途杀掉）。我在loadRecords里加了try-catch兜底，一旦发现JSON解析失败，就删除旧数据并返回空列表。这种“熔断式”降级策略虽然会牺牲用户的历史记录，但至少保证了App不会因数据损坏而崩溃。

另外要说一个非常重要的习惯：存储键名里加了版本号（search_history_records_v1）。以后mdash结构发生变化，直接换键名就行，避免兼容旧数据的逻辑把代码搞得越来越复杂。很多开发者在初期觉得版本号多余，等上线后被迫写迁移逻辑时才知道后悔。

3.3 搜索历史的裁剪策略

“最多20条”这个数字不是拍脑袋定的。我参考了几款主流搜索类App的做法，发现它们的搜索历史上限一般在10到30条之间。20条对垃圾分类场景足够：按一个家庭每周搜索5种垃圾计算，20条能覆盖接近一个月的高频查询。

裁剪发生在每次写入时：records.take(_maxRecords)会在插入并去重之后自动丢弃最末尾的超额记录。这里有个小设计——裁剪策略选择了“淘汰最旧”，如果以后想改成“淘汰最少使用”，只需要把排序逻辑从按时间改成按searchCount * 权重 + 时间衰减即可。数据模型预留的字段这时候就派上用场了，还是那句，数据结构设计要多想一步。

4. 页面交互实现：记录列表、回填逻辑与删除细节

数据层搞定，接下来是UI层。搜索历史的展示形态，我对比过几种主流方案：下拉展开式列表、带标签悬浮式、独立历史页面。考虑到垃圾分类指南App的搜索页是核心流量入口，不能给历史记录太多永久空间，最终采用了“搜索框聚焦时、输入为空时展示历史记录卡片”的设计。

4.1 历史记录组件：标签云与列表的取舍

历史记录我用了“标签云 + 顶部清空按钮”的样式。每个历史词条是圆角标签，右侧带一个关闭小图标。这里有个用户习惯问题：苹果系App偏好整个标签可点并可左滑删除，Material风格的App则更习惯点击标签直接回填搜索、点右侧X删除。我最终选了后者，原因很简单——在OpenHarmony上左滑删除手势需要联动滚动组件的手势竞技场，处理不当会让列表滚动变得卡顿，而在Flutter中左侧滑与纵向滚动的冲突是经典的手势识别难题，不值得为一个小功能引入这种复杂度。

标签排布用Wrap组件实现，间距统一8像素：

Wrap( spacing: 8, runSpacing: 8, children: records.map((record) { return InputChip( label: Text(record.keyword), onPressed: () => _onHistoryTap(record.keyword), deleteIcon: Icon(Icons.close, size: 16), onDeleted: () => _onDeleteSingle(record.keyword), ); }).toList(), )

用InputChip的好处是deleteIcon和onPressed天然区分，视觉上自带删除状态，不需要我自己去做Ripple和命中区域的嵌套处理。不过要注意：在OpenHarmony的ArkUI适配层，Flutter的Material组件渲染性能存在一些差异，特别是Chip这类包含大量圆角裁剪和状态色切换的组件。我在低端设备上实测，列表超过15个Chip后，快速点击时会有偶发的掉帧。

4.2 点击回填与搜索触发链路

点击历史词条后，我期望的行为是：搜索框立即填充该词，同时触发一次搜索并让键盘收起。这里我在Flutter中必须注意一个时序问题——TextEditingController.text的赋值需要放在FocusScope.of(context).unfocus()之后还是之前，直接决定了键盘收起的动画是否顺滑。经过反复试验，正确顺序是先收起键盘、再赋值、再触发搜索：

void _onHistoryTap(String keyword) { FocusManager.instance.primaryFocus?.unfocus(); // 这里不用setState，因为controller本身是响应式的 _searchController.text = keyword; _searchController.selection = TextSelection.fromPosition( TextPosition(offset: keyword.length), ); _performSearch(keyword); }

如果不主动设置selection，Flutter在iOS/Android上有时候光标会跳到文本最前端。此外，每次历史点击都应该重新触发一次搜索而不是只填充不处理，否则用户还要多按一次回车，体验明显不佳。

4.3 查询结果的状态联动

当前App的搜索结果页有加载中、空结果、正常结果、网络异常四个状态。搜索历史模块与之联动的逻辑是：如果用户点击历史词条后，结果页显示空结果，那么这条历史记录要保留（用户可能是在确认某个东西不属于可回收类别，这个行为本身是有效的）。但如果在搜索框内手动输入并搜索后0.2秒内就退出搜索页，则本次搜索不记录——这种“误触”行为不应该污染历史记录。

这个联动逻辑如果放在UI层做会很啰嗦，我选择在搜索请求发出前统一记录历史，然后在拿到结果后判断是否需要回滚。如果你不想做这么细，一个折中方案是记录历史延迟到“成功拿到非空结果”之后。但要注意，垃圾分类场景中“查不到结果”本身是有效行为，所以二段式的“先记录、后按结果修正”反而更合理。

5. 多页面状态下搜索历史的同步与组件通信

垃圾分类指南App不是只有搜索页一个入口。我在首页分类导航里也嵌了一个“查询入口”，用户从首页直接输入垃圾名称后，同样需要写入搜索历史，这就带来了“多个页面共享同一份历史数据”的问题。

5.1 组件通信的三种思路对比

在Flutter for OpenHarmony项目中，跨页面同步状态的方案有三种常见选择：

我优先排除了事件总线。搜索历史的场景虽然跨页面，但本质上只需要一个公共数据源，不涉及高频事件广播。事件总线写起来很爽，但一旦忘记在dispose中取消监听，就会出现“已销毁组件收到更新回调”导致的内存泄漏，在OpenHarmony上由于系统对后台进程更严格的管控，这种泄漏更容易被系统直接杀掉。

5.2 基于状态提升的存储库模式

最终我采用了“存储库模式（Repository Pattern）”：所有页面通过同一个SearchHistoryManager实例读写历史数据，内存中维护一份热点缓存，UI通过ChangeNotifier监听变化。

class SearchHistoryRepository extends ChangeNotifier { final SearchHistoryManager _manager; List<SearchRecord> _cache = []; SearchHistoryRepository(this._manager) { refresh(); } List<SearchRecord> get records => List.unmodifiable(_cache); Future<void> refresh() async { _cache = await _manager.loadRecords(); notifyListeners(); } Future<void> add(String keyword) async { await _manager.addRecord(keyword); await refresh(); } Future<void> remove(String keyword) async { await _manager.removeRecord(keyword); await refresh(); } Future<void> clear() async { await _manager.clearRecords(); await refresh(); } }

所有页面在初始化时通过Provider.of<SearchHistoryRepository>(context)获取同一个实例，页面A写入后调用notifyListeners()，页面B的监听器同步刷新。这套方案在多页面同步测试中表现稳定，唯一需要留意的是refresh()每次都全量重新读SharedPreferences，虽然量小，但也可能有毫秒级别的耗时。如果以后数据量变大，可以改为写入后直接在内存缓存中做增删操作，不必全量重读。

5.3 状态管理选型中的OpenHarmony定向考量

在Flutter for OpenHarmony社区里，状态管理库的兼容性并不完全一致。Provider和Riverpod在OpenHarmony上的Flutter适配层都能正常运行，因为它们的本质是InheritedWidget的封装；但Bloc这类依赖Stream的库在高频事件下偶尔会在OpenHarmony的异步调度器上出现事件堆积。我不是说Bloc在OpenHarmony上不可用，而是对于搜索历史这种“低频、对一致性要求高”的场景，Provider方案更轻、排查问题更容易——少一层StreamTransformer的封装，就少一类玄学问题。

6. OpenHarmony适配中的真实坑位：存储、动画与键盘

接下来是整篇文章的重头戏——我在OpenHarmony上调试这个搜索历史功能时实际踩过的坑，每个都带有可复现的排查思路和解决方案。

6.1 shared_preferences插件在碰鸿蒙设备上的存储路径差异

第一个坑就是存储路径。在标准Android上，shared_preferences的数据存在/data/data/<包名>/shared_prefs/下，而OpenHarmony的应用沙箱目录结构完全不同。我的App首次安装启动后会初始化一个随机目录作为沙箱根路径。用SharedPreferences.getInstance()时插件内部会通过getApplicationSupportDirectory()定位文件路径，这部分适配在OpenHarmony上已经实现。

但值得警惕的是，OpenHarmony对“应用卸载重装”的处理策略与Android不同：Android卸载时还会保留部分数据（视厂商而定），而OpenHarmony在标准环境下卸载即清除全部沙箱数据。如果你在开发垃圾分类App时需要保留用户的历史记录跨卸载周期，就必须额外把数据导出到用户公共目录或云端。我们的结论是“不保留”，搜索历史属于个性化缓存数据，随App生命周期管理是合理的。

6.2 清空历史按钮的确认弹窗与动画卡顿

清空历史是个不可逆操作，必须加二次确认。我用了showDialog包了一个AlertDialog。在普通Flutter上这没问题，但OpenHarmony上却有性能陷阱：当历史列表超过15条时，点击清空后执行列表移除动画，会让低端设备直接掉到40帧以下。定位后发现是AnimatedList移除多个条目时，每条目的动画同时执行，叠加了太多GPU绘制层。

解决方案很直接：清空时不做逐条移除动画，直接隐藏整个组件块并淡出。破碎的列表动画带来的视觉价值远低于性能损耗。在移动端凡是列表数量可能超过10个的批量操作，都要慎用逐项动画。

6.3 键盘弹出与搜索历史列表的避让冲突

搜索页在输入框聚焦时弹出历史记录，因此键盘避让逻辑很关键。我在OpenHarmony真机上遇到一个状态：点击历史词条时由于键盘未完全收起，搜索框被顶起，历史列表尚未刷新，导致点击的跳变感很强。最终方案是：

• 监听WidgetsBinding.instance.keyboardInsets变化。
• 当键盘高度变化时，将当前展示状态暂时标记为“收起中”，等搜索完成后再重建历史列表。
• 整个搜索过程不依赖键盘状态，只在结果页加载完成后重新设置SafeArea的内边距。

这种做法牺牲了一点点击瞬间的视觉反馈，但换来了稳定的布局表现。OpenHarmony的键盘弹出动画和输入法IME适配目前比Android略粗糙，开发者需要习惯在代码里做这种“主动钳制”。

6.4 Impeller引擎与圆角标签的渲染

Flutter 3.x后的默认渲染引擎是Impeller，OpenHarmony的Flutter适配分支也已支持。但impeller在部分GPU较弱的OpenHarmony设备上，对于大量圆角+阴影组合的控件渲染开销不小。InputChip恰好是典型的高开销控件：包含圆角矩形背景、波纹、前景图标。

我在真机上对比过，同样20个Chip，Impeller引擎渲染帧耗时比Skia引擎（可以通过--enable-software-rendering切换）高出12%左右。这不是说Impeller不行，而是建议开发者在这种场景下减少自定义阴影、用elevation: 0配合纯色背景替代，让渲染压力降下来。搜索历史标签不需要立体感的话，没必要给每个Chip加阴影。

6.5 XTS认证测试对InputChip无障碍标签的要求

提到OpenHarmony就绕不开XTS认证。应用如果要上架碰鸿蒙应用市场，需要过XTS兼容性测试。搜索历史里的InputChip图标按钮如果缺少无障碍语义标签，会在无障碍扫描项上被标记为失败。我的处理方式是在InputChip外层包一层Semantics：

Semantics( label: '删除 ${record.keyword} 的搜索记录', button: true, child: InputChip(...), )

这个标签既满足无障碍需求，也顺便让触屏朗读工具的用户能听懂删除含义。垃圾细分场景有不少老年用户，他们使用无障碍功能的概率比其他App高得多，这个细节不是应付认证，而是真实需求。

7. 测试策略与抓包调试：搜索历史模块怎么验证

功能开发完成不等于结束，搜索历史的测试也有不少门道，特别是涉及状态同步与异常数据恢复的场景。

7.1 单元测试：存储逻辑的竞态覆盖

我在SearchHistoryManager上写了单独的单元测试，重点覆盖三类：

• 连续快速添加去重逻辑：模拟5次快速搜索同一关键词，断言最终历史记录只有1条且searchCount符合预期。
• 超过20条后自动裁剪：先手动写入25条，断言列表长度为20且最早一条被淘汰。
• 损坏JSON数据的降级：给定一段非法字符串，断言返回空列表且不抛异常。

这些测试不依赖任何UI，跑起来非常快。测试环境里用SharedPreferences.setMockInitialValues({})注入初始值即可。

7.2 集成测试：跨页面同步的验证手段

跨页面同步在集成测试环境里验证起来比较麻烦。我的方案是写一个简单的端到端测试脚本，模拟在首页搜索入口提交关键词，然后立刻切换到搜索页，断言搜索历史列表已经包含这条记录。由于真实搜索引擎结果返回需要时间（而且无法保证网络状态），测试时我把搜索请求mock掉，只验证历史写入逻辑。

7.3 抓包与日志：定位“写入成功但显示不出来”的玄学问题

在开发中段，我遇到一个诡异问题：搜索页写入历史后，首页入口那个查询页拉到最新状态时偶尔不显示新记录。第一反应是网络同步问题，抓包后发现搜索请求正常返回，问题只出在UI刷新上。

排查过程回顾：SearchHistoryRepository在首页查询页被意外地创建了第二个实例，两处互不相通，写入只发生在搜索页那个实例，首页展示用另一个实例。Root cause是构造函数在某个环节被context变化重新初始化了。修正方式是把这个Repository实例提升到App顶层，用Provider在runApp之前创建，确保全局唯一。

这种问题在单页面App中几乎不会出现，但在Flutter for OpenHarmony这种多入口组件存在的时候，很容易因为对Provider作用域理解不透而写出两个隔离实例。排查时我一度怀疑OpenHarmony的Activity生命周期导致状态丢失，最后发现是自己对依赖注入容器没有做单例约束。

8. 后续演进：搜索历史模块能给整个App带来什么

搜索历史这个功能做到现在，基础链路已经完整：新增记录、去重合并、裁剪淘汰、单项删除、一键清空、跨页面同步、异常恢复、无障碍适配。但在开发过程中我明显感觉到，它完全可以成为整个App智能化升级的抓手。

第一个可落地的扩展是“常用垃圾智能排序”。如果用searchCount字段统计高频垃圾，在搜索框未输入时，可以把最近30天搜索次数最多的前10个词条做成“常用分类快捷入口”。这个功能对老年用户特别友好，不用打字，点击即查。数据准备阶段是纯本地的。

第二个扩展方向是“家庭共享垃圾桶管理”。用户可以把历史搜索同步到云端，家人共用一份垃圾投放记录，这个方向涉及账号体系和云端存储，复杂度会上一个台阶。搜索历史的timestamp和searchCount数据可以作为家庭垃圾分类行为分析的基础样本，比如帮用户总结“这周可回收垃圾查询次数最多的是哪个类别”。

第三个技术层面的改进是：把存储方案从shared_preferences迁移到更规范的地方。如果未来需要存储用户收藏的垃圾条目、图片识别结果等更丰富的数据，sqlite/drift就成了合理选项。到那时候，搜索历史表、收藏表、行为记录表之间还能做关联查询，比如“用户收藏过废电池，那它最近搜索过电池类相关词条吗”。

从我个人的开发体会来说，搜索历史这个“小功能”在Flutter for OpenHarmony这条路上是绝佳的练手项目——它麻雀虽小，却完整覆盖了数据持久化、状态管理、跨组件通信、平台适配、性能优化、无障碍合规这条全链路。把这些踩过的坑记录下来，不只是为了这篇博客，更是为了下次遇到类似需求时，能直接跳过那些不必要的试错环节。

最后分享一个实用调试技巧：在OpenHarmony的DevEco Studio里调试Flutter应用时，如果发现SharedPreferences的读写行为不确定，先别急着翻插件源码，可以先在App的沙箱目录里找到对应的XML文件（OpenHarmony路径一般是/data/app/el2/<包名>/shared_prefs/），直接查看文件内容确认数据是否写入成功，这一步能把“存储问题”和“UI问题”快速分开。这是我在排查“写入成功但显示不出来”问题时最有价值的一步，希望你用不上，但如果遇到了，能省下不少时间。