这套衣橱管家App从立项算起，断断续续写了两个月。业务逻辑本身不算复杂——衣物分类、穿搭推荐、换季收纳提醒，都是很常规的增删改查加上一点规则判断。真正让我花心思的是跨端适配，尤其是把Flutter代码搬到OpenHarmony上之后，一堆在安卓和iOS上完全不存在的坑冒了出来。这篇实战记录我就拿衣橱管家的使用帮助功能当主线，从项目设计、环境搭建、UI实现、数据落盘一路讲到问题排查，把Flutter for OpenHarmony的开发全流程摊开讲。如果你正在做类似的跨端工具类App，或者正准备把存量Flutter工程适配到鸿蒙系统，这篇应该能帮你省掉几个晚上的查资料时间。
1. 项目背景与整体设计思路
1.1 为什么选了Flutter做OpenHarmony端
先说选型背景。团队在做的这个衣橱管家，安卓、iOS、Web三端已经统一在Flutter技术栈上，当时评估OpenHarmony支持时只有两条路：要么用ArkUI重写一版，要么把现有Flutter工程适配过去。前者的代价很明显，UI层重新开发不说，后续每加一个功能都要三端并行改，小型团队根本扛不住。所以我们的判断很直接：一套Flutter代码能解决的问题，没必要写两套。
OpenHarmony官方并没有把Flutter列为第一方框架，但这个领域的适配并不缺人做。OpenHarmony-SIG组织维护着一套flutter_flutter和flutter_engine的fork仓库，提供专门的ohos分支，把Dart代码编译产物接入OpenHarmony的运行环境，Flutter的渲染引擎和组件层在OH上基本能跑起来。我用API 10版本的SDK实测下来，Material组件、路由导航、Canvas绘制这些核心能力是可用的，日常业务开发的体验接近安卓。当然也有不少细节需要额外处理，这部分后面具体讲。
选Flutter还有一个隐性好处：团队不需要额外学习ArkTS的声明式开发范式，DSL写法虽然和Dart有点像，但真要深入还是有不少学习成本。相比之下，Flutter的路由、状态管理、UI组件都能直接复用，人员上手周期几乎可以忽略。当然，选型也不是没有顾虑，最大的一个是Flutter在OpenHarmony上的生态成熟度，引擎的发行版、插件适配度、性能优化工具链都还在爬坡期，这些没法回避，只能靠工程手段一点点补。
1.2 衣橱管家的使用帮助功能包含哪些模块
衣橱管家本质上是一个工具类App，核心功能包括衣物信息录入、分类标签管理、每日穿搭推荐、换季收纳提醒。这类产品的用户群跨度很大，既有喜欢折腾穿搭的年轻人，也有帮全家人整衣柜的居家用户，使用经验参差不齐。如果用户第一次打开App不知道如何录入一件衣服、怎么建立自己的衣柜，大概率会直接删除，所以我把帮助做成了一个独立的一级模块，而不是藏在设置里的次级入口。
帮助模块拆成四个子页面：新手引导、常见问题、意见反馈、关于我们。新手引导负责第一印象，用三页轮播讲清楚核心操作的路径；常见问题收集了衣物分类规则、推荐逻辑、数据备份这些高频疑问，用折叠列表呈现；意见反馈是用户和我们之间的单向通道，先落本地再异步上传；关于我们承载版本号、版权信息和技术标识。这四个页面加在一起，就是一个完整的使用帮助闭环。
设计上我刻意把帮助模块做成了静态为主的产品。除了意见反馈需要写入数据，其余页面都是配置驱动，数据从本地assets读取，不依赖网络。这样一方面保证离线可用，另一方面也规避了OpenHarmony上网络权限、域名校验这些额外配置项。对于功能型产品来说，帮助模块的可用性比实时性重要得多，用户遇到问题的时候往往是连不上网的时候，本地化内容是安全的选择。
1.3 信息架构与页面流转设计
页面流转我没有引入路由框架，直接使用Flutter原生的Navigator。帮助主页用一个ListView承载四个入口卡片，点击后通过MaterialPageRoute跳转到对应子页面。为什么这么保守？因为帮助模块的页面关系都是浅层的一级跳转，不存在复杂的参数传递、拦截器、深链需求，用路由框架反而多一层维护成本。在OpenHarmony适配阶段，依赖越少排查问题越快，这是我踩过坑之后的最大体会。
子页面之间也没有做交叉跳转。新手引导结束会回到主页，FAQ点开是纯文本答案，反馈提交成功回到主页，关于我们页干脆没有按钮，逻辑彼此独立。这种"星型"结构的好处是任何一个页面出问题都不会影响其他页面，在跨端适配时尤其方便分模块验证。整个模块不需要全局状态，不需要持久化中间数据，唯一的状态就是新手引导是否已读，用一个SharedPreferences键值就能解决。
2. OpenHarmony侧Flutter环境搭建
2.1 获取OpenHarmony版Flutter SDK
搭建环境是跨端开发的第一道关，也是最容易卡住的地方。OpenHarmony的Flutter不能直接用flutter官方网站的SDK，需要从OpenHarmony-SIG组织维护的仓库拉取专门的fork版本。我这边是把flutter_flutter和flutter_engine两个仓库都拉下来，切换到对应OpenHarmony API版本的ohos分支，然后编译出可用的flutter命令和引擎产物。仓库分支和OpenHarmony SDK的API级别必须严格对齐，比如我用的是API 10，那么flutter_flutter也要切到配套的openharmony分支。
环境变量配置的几个关键项包括：DEVECO_SDK_HOME指向OpenHarmony SDK根目录，PATH里加入flutter_ohos的bin目录，如果flutter命令需要编译生成，还要确认本地的Dart SDK版本匹配。配置完成后在终端执行flutter doctor，如果能正确识别出OpenHarmony的toolchain，说明基础环境已经就绪。这里有个小提醒：尽量用官方推荐的LTS版本组合，追求最新版本的代价往往是编译时遇到尚未适配的坑，投入产出比很低。
2.2 DevEco Studio工程创建与运行配置
工程创建分两步。第一步用flutter create命令生成标准Flutter工程，这会生成包含lib、android、ios、web的常规目录结构。第二步是让工程适配OpenHarmony，在这个阶段，工具会自动补上一个ohos目录，这就是OpenHarmony侧的原生壳工程，类似android和ios目录的角色。ohos目录下会有一个oh-package.json5文件，管理OpenHarmony侧的依赖项，这个文件的依赖版本需要和Flutter引擎版本匹配，很多奇怪的编译错误都是因为这里没对齐。
开发时我用DevEco Studio打开工程，选中ohos目录作为项目根目录，IDE才能正确识别OpenHarmony的构建配置。DevEco Studio里需要提前安装Flutter插件，这样可以在IDE内直接调用flutter命令，还能方便地管理OpenHarmony SDK。首次构建时，直接执行OpenHarmony的hvigor构建任务。如果构建过程报错，优先检查两个地方：oh-package.json5里依赖的版本号，以及本地Flutter SDK的版本号，这两个信息一旦不一致，报错信息往往晦涩难懂，但根因基本都出在这里。
2.3 hdc连接模拟器与首次启动
OpenHarmony的命令行工具是hdc，用起来和安卓的adb高度相似。先启动DevEco Studio自带的模拟器，或者用USB连接OpenHarmony真机，然后执行hdc list targets查看设备列表，确认设备在线之后，就可以用flutter run -d设备号把应用跑起来。首次启动会执行完整的构建流程，HAP包编译、Flutter引擎打包、部署安装，整个过程比安卓侧稍慢，需要一点耐心。
这里要特别说一句热重载的事。OpenHarmony分支上的热重载目前还做不到安卓那么稳定，有时候改完Dart代码重新r，界面纹丝不动，看起来像没生效。我遇到的频率大概十次里有三四次，处理办法是杀掉App重新flutter run，或者用hdc shell aa restart从命令行强制拉起应用。别因为这个就怀疑项目配置有问题，这是当前工具链的已知短板，老老实实重启就行。另外，模拟器的性能和真机差距明显，建议把真机调试作为主要验证方式，模拟器只用来验证基础功能是否通。
3. 帮助模块UI与交互实现
3.1 帮助主页：用卡片导航组织功能入口
帮助主页是整个模块的入口，我用最保守的卡片列表方案：四个入口卡片垂直排列，每个卡片左侧一个圆角图标容器，中间是标题加一句话副标题，右侧放一个chevron_right箭头。这个布局在手机上几乎不会出问题，在OpenHarmony上也没有兼容性风险。为什么不搞九宫格或者侧边栏？因为帮助功能总共就四个入口，九宫格会显得稀疏，侧边栏在窄屏上浪费空间，垂直卡片是最不折腾的方案。
核心代码是一个ListView加上一个抽出来的卡片组件，每个卡片点击后通过Navigator.push跳转到对应子页面。实现这部分的细节有几个：卡片用Card组件包ListTile，图标统一放到CircleAvatar里，颜色从Theme读取而不写死，方便后续换主题；副标题控制在十五个字以内，避免两行截断影响视觉整齐度。代码结构上我把卡片抽成私有方法，四个入口的差异只有图标、标题和跳转目标，其他全部复用，整个页面代码不到八十行，维护起来很轻松。
import 'package:flutter/material.dart'; import 'guide_page.dart'; import 'faq_page.dart'; import 'feedback_page.dart'; import 'about_page.dart'; class HelpCenterPage extends StatelessWidget { const HelpCenterPage({super.key}); @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar(title: const Text('使用帮助'), centerTitle: true), body: ListView( padding: const EdgeInsets.all(16), children: [ _buildEntryCard( context, icon: Icons.lightbulb_outline, title: '新手引导', subtitle: '三分钟看懂衣橱管家', onTap: () => Navigator.push( context, MaterialPageRoute(builder: (_) => const GuidePage()), ), ), _buildEntryCard( context, icon: Icons.faq_outlined, title: '常见问题', subtitle: '衣物录入、搭配推荐、换季收纳', onTap: () => Navigator.push( context, MaterialPageRoute(builder: (_) => const FAQPage()), ), ), _buildEntryCard( context, icon: Icons.feedback_outlined, title: '意见反馈', subtitle: '你的建议是我们改进的动力', onTap: () => Navigator.push( context, MaterialPageRoute(builder: (_) => const FeedbackPage()), ), ), _buildEntryCard( context, icon: Icons.info_outline, title: '关于我们', subtitle: '版本信息与合作联系', onTap: () => Navigator.push( context, MaterialPageRoute(builder: (_) => const AboutPage()), ), ), ], ), ); } Widget _buildEntryCard(BuildContext context, { required IconData icon, required String title, required String subtitle, required VoidCallback onTap, }) { final theme = Theme.of(context); return Card( margin: const EdgeInsets.only(bottom: 12), child: ListTile( leading: CircleAvatar( backgroundColor: theme.colorScheme.primaryContainer, child: Icon(icon, color: theme.colorScheme.primary), ), title: Text(title, style: const TextStyle(fontWeight: FontWeight.w600)), subtitle: Text(subtitle), trailing: const Icon(Icons.chevron_right), onTap: onTap, ), ); } }有人可能会问，为什么不用GridView做成两列四宫格，视觉效果不是更丰富？我的考虑是帮助入口的卡片文字信息量不小，两列布局会把副标题挤得很窄，用户扫读效率反而下降。单列卡片配合较大的点击区域，对工具型产品是更友好的交互模式。这个决策在后续真机适配时也得到验证，OpenHarmony上不同屏幕尺寸的显示效果都很稳定。
3.2 新手引导：PageView滑动与指示器动效
新手引导页承载三页说明，内容是衣物录入、搭配推荐、换季收纳三个核心功能的图文介绍。这个页面在Flutter里实现有一套非常标准的组合：PageView负责滑动，底部用一行小圆点指示当前位置，最后一页放一个"开始使用"按钮，点击后调用SharedPreferences写入已读标记。
PageView的使用比较简单，关键是底部指示器的动效。我用了AnimatedContainer，当前页对应的指示器会从灰色小圆点变为主题色圆角条，宽度从8像素拉伸到20像素，这样用户滑动时能明显感知页码变化。切换动画的触发点是PageView的onPageChanged回调，每次页码变化都重新build一次指示器行，配合150毫秒的动画时长，视觉效果顺滑又不抢戏。
class _GuidePageState extends State<GuidePage> { final PageController _controller = PageController(); int _currentPage = 0; @override Widget build(BuildContext context) { return Scaffold( body: SafeArea( child: Column( children: [ Expanded( child: PageView.builder( controller: _controller, onPageChanged: (index) => setState(() => _currentPage = index), itemCount: 3, itemBuilder: (context, index) => _GuideItem(index: index), ), ), Row( mainAxisAlignment: MainAxisAlignment.center, children: List.generate(3, (i) { final active = i == _currentPage; return AnimatedContainer( duration: const Duration(milliseconds: 150), width: active ? 20 : 8, height: 8, margin: const EdgeInsets.all(4), decoration: BoxDecoration( color: active ? themeColor : Colors.grey, borderRadius: BorderRadius.circular(4), ), ); }), ), Padding( padding: const EdgeInsets.all(24), child: FilledButton( onPressed: _currentPage == 2 ? _finishGuide : null, child: const Text('开始使用'), ), ), ], ), ), ); } }新手引导有几个容易忽略的细节。一是"开始使用"按钮只在最后一页可点，前两页保持禁用状态，避免用户误触中断说明；二是引导页如果支持横屏，PageView到了边缘会有回弹效果，需要在PageScrollPhysics上做处理，我这边直接把App锁成竖屏，省了这个麻烦；三是引导完成状态要确保能正确写入，否则每次启动都重新走引导流程，用户会非常烦躁。状态写入成功后再跳转主页，我加了一个简单的await保证。
3.3 常见问题：ExpansionTile数据驱动实现
FAQ页的功能很单纯：展示问题列表，点击问题展开答案。数据上我选择了把FAQ放在assets目录下的JSON文件里，结构是一个包含question和answer字段的对象数组。页面启动时通过rootBundle.loadString读取文件，解析成List ，然后交给ListView.builder渲染。整个列表用ExpansionTile作为行组件，默认收起，点击后展开显示答案。
为什么不把FAQ直接写死在Dart代码里？答案很简单：后期维护。FAQ的内容大概率会跟着产品迭代频繁更新，如果写死在代码里，每次改一个问答都要重新走一遍发版流程。放在JSON文件里的好处是内容与逻辑分离，后续甚至可以直接把这个文件替换成网络接口返回的数据，UI层完全不需要改动。代码里我封装了一个FAQItem模型类，fromJson方法处理字段映射，加载过程用FutureBuilder或者initState里异步等数据都行。
ExpansionTile本身是个标准Material组件，OpenHarmony分支上表现基本正常。有一个坑值得提一下：ExpansionTile在展开后默认会带一个圆角边框和上下分隔线，在深色模式下视觉上会多出一圈奇怪的描边。解决办法是给ExpansionTile显式设置shape和collapsedShape为空边框，同时设置dividerColor为透明，这样展开收起时视觉过渡才干净。这个细节我在主题适配时花了不少时间才注意到。
3.4 意见反馈：表单校验与本地落盘
意见反馈是整个帮助模块里唯一涉及写入的页面，也是我当时花时间最长的部分。页面上放了一个Form，包含反馈内容和联系方式两个输入项，反馈内容用多行TextFormField承载，最大长度限制500字，设置了必填校验；联系方式选填，用手机号或邮箱的格式校验。表单下方是一个全宽按钮，点击后先走Form校验，通过后再执行落盘逻辑。
落盘方案我做了具体的设计：使用path_provider插件获取应用文档目录，把反馈内容、联系方式、提交时间、当前页面版本写入一个文本文件，文件名用时间戳加前缀区分，例如feedback_1734567890123.txt。为什么不直接接后端？因为后端接口还没排期，反馈数据先本地缓存，后续有网络条件再批量上传。对帮助模块来说这个方案既完成了数据收集，又不阻塞当前版本上线，实际效果完全够用。
Future<void> _submit() async { if (!_formKey.currentState!.validate()) return; setState(() => _submitting = true); final dir = await getApplicationDocumentsDirectory(); final fileName = 'feedback_${DateTime.now().millisecondsSinceEpoch}.txt'; final file = File('${dir.path}/$fileName'); await file.writeAsString( '内容: ${_contentController.text}\n' '联系方式: ${_contactController.text}\n' '时间: ${DateTime.now()}\n' '版本: $_appVersion\n', ); if (!mounted) return; setState(() => _submitting = false); ScaffoldMessenger.of(context).showSnackBar( const SnackBar(content: Text('感谢反馈，我们会尽快处理')), ); _contentController.clear(); _contactController.clear(); }提交成功后的交互我特意做了两点：一是提交按钮短暂进入loading态，防止用户连续点击产生重复文件；二是清空输入框并弹一个SnackBar提示。这里有个小建议，反馈框里最好预填一个"当前页面是什么问题"的上下文标记，否则用户写的反馈经常是孤立的抱怨，没有场景信息，后续处理时很难定位问题。衣橱管家这边我妥协了一下，把主页入口的页面名写进了文件名元数据里，至少能知道反馈来自哪个页面。
3.5 关于我们与设备信息：平台通道的巧用
关于我们页是帮助模块里最容易被忽视的页面，但恰恰是它让我深入地接触到了Flutter和OpenHarmony两端的平台通道适配。页面内容包括App图标、版本号、版权信息和一行"Flutter + OpenHarmony构建"的技术标识。版本号常规做法是读package_info_plus插件，但当时这个插件在OpenHarmony分支上的适配还不完整，我就在pubspec里手动维护了一个版本常量，从配置里读取，绕开了插件兼容问题。
页面底部我加了一个不太起眼的小功能：显示当前设备的系统版本和剩余电量。这个数据Flutter侧拿不到，必须通过MethodChannel和EventChannel从OpenHarmony原生侧获取。MethodChannel用来一次性查询系统版本，EventChannel用来持续监听电量变化。在帮助页面展示设备信息是一个很实用的诊断手段，用户反馈问题时直接把页面截图发过来，我们就能知道他的设备环境和电量状态，排查效率高很多。
Flutter侧的代码很短，核心就是注册一个事件流并消费数据：
static const EventChannel _batteryChannel = EventChannel('app.wardrobe/battery'); _batteryChannel.receiveBroadcastStream().listen( (event) { setState(() => _batteryLevel = event.toString()); }, onError: (e) { _batteryLevel = '未知'; }, );OpenHarmony侧的注册逻辑在ohos目录的原生代码里，需要用ArkTS实现一个EventChannel的StreamHandler，负责在onListen时向外推送电量数据。这里有一个关键教训：Flutter侧注册Channel时使用的包名，和OpenHarmony侧注册时必须完全一致，否则事件会静默丢失，连报错都不弹。我第一次遇到这个问题时排查了整整一个下午，最后才发现是两端channel名大小写不一致。这种问题在跨端开发里特别隐蔽，因为编译不报错、运行不崩溃，就是数据不通。
4. 数据管理与工程化细节
4.1 FAQ数据用JSON还是数据库
做FAQ之前我认真考虑过数据存储方案。数据库当然是更"专业"的选择，sqlite足以承载几千条问答，还能做模糊搜索，但在衣橱管家这个场景里，FAQ数据量不到二十条，更新频率非常低，引入数据库明显是过度设计。最终我选用了assets目录下的JSON文件，问题和答案以对象数组形式存放，启动时一次性加载到内存。这个方案的优缺点都很明确：优点是轻量、离线可用、内容修改方便；缺点是不支持服务端热更新，内容变更必须跟随发版。
如果未来想把FAQ做成可在线更新的版本，切换到网络数据源的成本其实很低。只需要把rootBundle.loadString替换成一个GET请求，然后把返回的JSON字符串交给同一个解析逻辑即可，UI层和模型层完全不需要动。这也是我坚持把数据与UI分离的原因，先做本地版本，再平滑演进到远端，避免一开始就把架构锁死。
4.2 反馈内容的本地存取策略
反馈数据落盘后，还有一个容易被忽略的问题：文件多了之后如何管理。理论上用户每次提交反馈都会生成一个新的txt文件，几个月下来目录里的文件会堆积。我在代码里做了一个轻量的定期清理逻辑：每次启动App时检查反馈目录，文件数量超过五十个就把最早的那批删除，保留最近的数据。这个逻辑虽然简单，但能防止反馈文件无限增长占用用户存储空间，细节虽小，体验差异很大。
另一个切入点是文件内容的可读性。我刻意把反馈文件写成了纯文本格式，每行一个字段，而不是塞一个JSON。原因是运维和客服同学拿到文件后不用解析工具也能直接读懂，降低协作门槛。如果后续要对接后端上传，只要在发送前把这几个字段组装成JSON即可，现在这种纯文本格式反而保留了最大的灵活性。
4.3 主题样式与多端适配
帮助模块的视觉风格我尽量向衣橱管家的整体设计对齐，主色、圆角、间距都来自全局ThemeData，不在页面里写死数值。这么做的好处是后续如果调整品牌色，只需要改一处，四个帮助子页面自动跟随。文字排版上，标题用w600字重，正文保持默认字重，行距交给TextTheme处理。这些细节在安卓、iOS、OpenHarmony三端渲染结果基本一致，差异主要是字体Fallback，中文场景下几乎看不出来。
暗色模式是Flutter适配OpenHarmony时需要注意的点。我在每个页面都用Theme.of(context)读取颜色，而不是直接写Colors.white之类的字面量，这样系统切换暗色模式时页面UI能自动响应。有一个细节值得特别注意：ExpansionTile在暗色模式下的展开边框、Card在暗色模式下的阴影表现，都跟亮色模式不同，需要在开发阶段就测试一遍。衣橱管家上线后有不少用户喜欢用暗色模式，这个适配工作提前做能省后续很多工单。
5. 踩坑实录：OpenHarmony适配问题排查
5.1 Flutter SDK版本与ohos依赖对齐
OpenHarmony上Flutter适配最容易踩的坑，排第一的一定是版本对齐问题。我遇到过最典型的一个报错是The current configured Flutter SDK is not known to be fully supported，这种提示在Flutter官方版本上偶尔也会出现，但OpenHarmony分支上出现的频率要高得多。根本原因就是本地的flutter命令版本、flutter_engine产物版本、以及ohos目录下oh-package.json5里声明的engine依赖版本三者没有对齐，构建时任何一个环节不一致都会抛出这类错误。
我的解决办法是建立一套固定的版本基线：flutter_flutter分支固定到对应OpenHarmony API版本的标签，oh-package.json5里的flutter_engine依赖也固定到同一个版本号，升级时必须三个一起升，拆开升级必出幺蛾子。实际开发中我总结出一个更土但有效的判断方法：如果构建报错出现在编译早期且指向engine或plugin相关类，不用看细节，直接检查版本对齐就对了，十有八九问题出在这里。
5.2 帮助页组件的OpenHarmony兼容性处理
帮助模块用到的Flutter组件，我在适配过程中基本逐个验证过。整体结论是Material组件在OpenHarmony分支上的兼容性已经相当不错，AppBar、ListView、Card、ListTile、PageView、ExpansionTile这些组件都能正常工作，渲染效果和安卓端差别不大。但有几个细节例外，我做了一个简单的兼容性对照：
| 组件/能力 | OpenHarmony表现 | 处理建议 |
|---|---|---|
| AppBar、ListView、Card、ListTile | 正常 | 直接使用 |
| PageView + AnimatedContainer | 正常 | 直接使用 |
| ExpansionTile | 展开时有额外边框 | 显式设置shape参数 |
| InkWell波纹动画 | 偶发不显示 | 改用GestureDetector或IconButton |
| TextField中文输入 | 输入法偶发异常 | 检查IME插件版本 |
| PlatformView | 适配不成熟 | 尽量避开核心路径 |
InkWell的波纹问题我实际遇到好几次，渲染层没有任何报错，但点击后就是没有涟漪反馈。这种问题最费神，因为没有错误日志可查。后来我养成了一个习惯：凡是需要点击反馈的组件，统一用GestureDetector包一层，或者直接用IconButton、FilledButton这些自带手势处理的组件，从源头上绕开InkWell带来的不确定因素。
另一个坑是PlatformView的使用。帮助模块本身不涉及原生View嵌入，但如果你的App里用了webview或者MapView，在OpenHarmony上要格外小心，PlatformView的适配是目前最不成熟的部分之一。我周围有朋友做OpenHarmony适配时在PlatformView上卡了好几周，建议是尽量把这类需求从核心路径中挪开，先用容器页面承载，等引擎优化后再回归。帮助功能这类轻量模块反而是最适合做OpenHarmony试水的，组件覆盖面广但复杂度低，踩坑成本可控。
5.3 真机部署、包体优化与发布备忘
部署细节点比较碎，我一条一条列出来希望对你有用。hdc连接设备前先确认开发者模式已打开，USB调试授权弹窗要点击允许，否则hdc list targets看不到设备。HAP包默认需要签名才能在真机安装，DevEco Studio的自动签名配置要提前开通，否则安装时会报签名错误。每次重新构建前先清理旧包，否则偶发出现旧资源未更新的问题。
包体大小方面，首版真机安装包大概在九十多兆，其中Flutter引擎占了大部分。优化方向有两个：一是裁剪不需要的引擎so文件，OpenHarmony的Flutter支持按CPU架构拆包，发布时只保留目标架构；二是压缩assets资源，把FAQ配图转成WebP格式。整体下来能压缩到六十兆左右。适配期我建议别过早纠结体积，先把功能跑通，上线前再做优化，效率会高很多。
发布到应用市场还有一层审核验证流程，不同市场的OpenHarmony应用要求不太一样，有的会要求提供兼容性测试报告，有的会检查权限声明是否超范围，这些在提交前都要逐项核对。我这次只上了一个内部渠道，流程相对简单，但也花了不少精力核对权限和隐私说明，建议你们提前把隐私政策页面准备好，帮助模块里的关于我们页正好可以放一个隐私政策入口，一举两得。
回顾整个适配过程，我对Flutter for OpenHarmony的判断是这样的：它已跨过"能不能用"的临界点，但离"好不好用"还有距离。如果你正在评估鸿蒙适配，最好的方式不是拿着全部代码硬上，而是先挑一个像帮助模块这样的典型功能来试水。它覆盖了路由跳转、列表渲染、表单输入、数据持久化、平台通道这几个跨端开发最常见的场景，把这个模块在OpenHarmony上跑稳了，等于把整个App的技术骨架先打通了。衣橱管家后面还会加云端备份、多端同步这类重功能，到时候帮助模块这套本地优先、配置驱动的底子可以直接复用。适配跨端系统这件事，没有一步到位的银弹，能做的就是把每个模块拆解清楚，逐个验证，逐步推进。希望这篇记录能帮你少走一段弯路。
