Flutter鸿蒙适配实战：从环境搭建到应用打包全流程解析

两年前我第一次尝试把 Flutter 应用跑上鸿蒙设备时，光是环境配置就折腾了整整一个周末。当时网上资料少，群里逮着人就问，好心的朋友丢来一个仓库链接，我对着 README 一步步试，最后看到模拟器里弹出 Hello World 那一刻，还是有点激动的。这次做“谜语大全”，项目不大，但完整走了一遍从需求分析、技术选型到打包适配鸿蒙全流程，中间踩了不少坑，也积累了一些值得说的经验，整理出来给准备用 Flutter 碰鸿蒙的朋友做个参考。

1. 为什么一个“谜语大全”非要跨平台选 Flutter

1.1 这个需求到底是不是伪需求

很多人看到“谜语大全”四个字，第一反应是：这不就是个玩具项目吗？随便用 WebView 套个网页或者原生写个列表就能搞定，至于上 Flutter 吗？

我先说说最初的诉求。我手上有一台鸿蒙手机、一台安卓备用机，未来还想顺手出个 iOS 版本。谜语这种内容型应用，功能看起来简单，真要把分类浏览、搜索、收藏、随机出题、每日推荐、猜题记录这些模块完整铺开，页面文件加在一起也有几十个。原生开发意味着每端各写一遍，双倍成本不说，后续维护也痛苦。跨平台框架的核心价值不是“写一次跑三端”这种理想口号，而是尽量把 UI 和业务逻辑的复用率提上去，让团队把精力留给交互和内容。

还有人会问，鸿蒙原生开发用 ArkTS 加 ArkUI 也挺好，为什么非要 Flutter？我承认 ArkUI 在鸿蒙上的表现确实不错，声明式UI写起来也顺手。但一个现实问题是：我不可能只为鸿蒙单独维护一套代码，跨平台选型首先要看未来的多端覆盖能力。Flutter 最大的优势在于渲染层不依赖系统原生控件，它的引擎在鸿蒙上的适配进度，目前来看是所有跨平台方案里最积极的，社区适配已经能支撑真实项目跑通。

1.2 Flutter 跑在鸿蒙上的原理：不是魔法，是“自绘引擎 + 宿主壳”

理解 Flutter 为什么能适配鸿蒙，得先搞清楚它的渲染链路。传统跨平台方案比如 React Native，最终要把 JS 组件映射成系统原生控件，所以每到一个新平台，就要重新适配一套控件映射，工作量和坑都不少。而 Flutter 走的是另一条路：它自带了 Skia 图形引擎（新版本在迁移到 Impeller），所有界面都是 Dart 代码直接调用引擎绘制出来的像素，不经过系统原生 UI 组件。

也就是说，Flutter 需要跑在鸿蒙上，核心不是“让系统认识 Flutter 控件”，而是“在鸿蒙系统里有一个能够运行 Dart 代码和 Flutter Engine 的宿主环境”。目前开源社区维护的 flutter_flutter 仓库，就是专门针对 OpenHarmony 和 HarmonyOS 的分支，配合适配过的 Flutter Engine，相当于在鸿蒙侧用 ArkTS 写了一个壳 Application，然后在里面启动 Flutter 的 Engine 并挂载 Dart 入口。这就是为什么采用这个技术方案后，你在鸿蒙上看到的界面和安卓、iOS 上几乎一模一样，因为 UI 本来就是同一套自绘结果，只是宿主环境不同。

搞明白了这一点，后面的很多问题就好理解了。比如某些原生插件在鸿蒙上不能直接用，是因为插件底层调用的是 Android API 或者 iOS API，而不是 Flutter 本身的问题。跨平台的边界，永远在“平台通道”这一层。

2. 环境搭建：三个版本选对，能省一整天

2.1 DevEco Studio、Flutter SDK 和 JDK 怎么匹配

先给一个经验总结：鸿蒙 Flutter 开发，最大的坑不是写代码，而是环境版本不匹配。我刚开始装的时候，随手下了最新版 DevEco Studio，又拉了一个最新的 Flutter stable 分支，结果创建工程后一堆莫名奇妙的编译错误，排查到最后才发现是 SDK 版本和 Flutter 工具链不兼容。

我最后稳定的组合是下面这套，仅供参考：

装好之后，检查 flutter doctor 能不能识别到鸿蒙环境。这里有个容易忽略的操作：社区版 Flutter SDK 默认不会自动识别 DevEco 的 SDK 路径，需要在环境变量里手动配好 DEVECO_SDK_HOME（不同分支可能叫法略有差异，建议直接看对应仓库 README）。我有个朋友卡在这一步很久，一直提示找不到 HarmonyOS SDK，配置完环境变量重启终端就好了。

2.2 创建工程与第一波报错：Gradle 与 CMake

环境就绪后，创建工程用下面的命令：

bash复制flutter create --platforms ohos .

相比普通 Flutter 工程，这个命令会多生成 ohos 目录，里面是鸿蒙侧的壳工程，结构上和原生鸿蒙应用一致，有 entry 模块、module.json5 等文件，后续打包、签名、权限声明都在这里操作。

第一个高频报错就是这段（网上搜索量很大）：

text复制You are applying Flutter's main Gradle plugin imperatively using the apply script

这个问题的根源是：较新版本的 Flutter 工具链开始推荐用声明式方式在 settings.gradle 里加载 Flutter Gradle 插件，而旧模板工程还在用 apply from: 脚本方式。解决思路就是按照报错提示，修改 android/settings.gradle 和根 build.gradle，把 Flutter 插件改成新语法：

groovy复制plugins {
    id "dev.flutter.flutter-plugin-loader" version "1.0.0"
    id "com.android.application" version "8.3.2" apply false
}

如果这个报错出现在鸿蒙侧，逻辑也一样，检查 ohos 目录下是否有类似加载 Flutter 插件脚本的地方，改为新的插件加载方式。

第二个高频报错是 Windows 上编译带原生代码的插件时，出现 CMake 错误：

text复制CMake Error at CMakeLists.txt:3 (project):
Generator Visual Studio 16 2019 could not find any instance of Visual Studio

原因是插件里的 C++ 代码需要 CMake 生成 Visual Studio 工程，但本机没有安装对应版本的 VS C++ 桌面开发组件。解决方法是安装 Visual Studio 2022 时勾选“使用 C++ 的桌面开发”工作负载，或者在 Flutter 工程里指定 CMake 生成器。装完 VS 基本就解决了。

环境这块我的建议是：别追求新、别追着官方 stable 跑，用社区 ohos 分支测试过的组合。社区分支比官方稳定版滞后一两个版本，但这是为了兼容性有意为之，乱换版本只会增加排查成本。

3. 谜语大全核心模块拆解：数据、列表、搜索与随机

3.1 谜语数据模型设计

谜语这种内容型数据，字段设计直接决定后面功能的实现难度。我第一版只存了谜面和谜底，后来做分类和难度筛选时发现数据模型不够用，又回头补字段、写迁移，麻烦得很。最终模型长这样：

dart复制class Riddle {
  final int id;
  final String category;   // 字谜、成语谜、动物谜、地名谜……
  final String riddle;     // 谜面
  final String answer;     // 谜底
  final String analysis;   // 解析
  final int difficulty;    // 1-3，初级/中级/高级
  final int hits;          // 点击次数，用于“热门排序”

  Riddle({
    required this.id,
    required this.category,
    required this.riddle,
    required this.answer,
    required this.analysis,
    required this.difficulty,
    this.hits = 0,
  });

  factory Riddle.fromJson(Map<String, dynamic> json) {
    return Riddle(
      id: json['id'] as int,
      category: json['category'] as String,
      riddle: json['riddle'] as String,
      answer: json['answer'] as String,
      analysis: json['analysis'] as String? ?? '',
      difficulty: json['difficulty'] as int? ?? 1,
      hits: json['hits'] as int? ?? 0,
    );
  }
}

category 为什么用字符串而不是枚举？因为我发现谜语分类很容易越分越细，比如“成语谜”下面还有“常用成语”“生僻成语”的说法，枚举会频繁改代码，字符串配合索引查询更灵活。数据来源上，我准备了大约 500 条汉字谜语和脑筋急转弯作为内置内容，存储在 assets/data/riddles.json 里，第一版直接随应用加载。下面是一条真实数据的例子：

json复制{
  "id": 1001,
  "category": "字谜",
  "riddle": "一口咬掉牛尾巴",
  "answer": "告",
  "analysis": "“牛”字失去下半部分，上面被“口”咬住，组成“告”。",
  "difficulty": 1,
  "hits": 3280
}

3.2 列表、分类与“翻牌”猜谜交互

首页我用了三栏结构：顶部分类筛选、中间谜语列表、底部随机出题按钮。分类筛选用横向滚动的 ChoiceChip 列表实现，选中某个分类后，列表数据源切换成对应的分类谜语集合。

列表部分核心代码很简单，要注意的是 ListView.builder 的 itemExtent 参数。谜语卡片高度固定的话，加上这个参数可以大幅提升滚动性能：

dart复制ListView.builder(
  itemExtent: 88, // 固定卡片高度，滚动时减少计算
  itemCount: riddles.length,
  itemBuilder: (context, index) {
    final riddle = riddles[index];
    return RiddleCard(riddle: riddle);
  },
)

猜谜页的交互参考了很多答题类 App：显示谜面，点击后卡片 3D 翻转露出谜底。这里用 Flutter 自带的 AnimatedBuilder 配合 AnimationController 就能实现，不需要引入额外库。核心思路是绕 Y 轴旋转，前半段显示谜面，角度超过 90 度后切换谜底：

dart复制AnimatedBuilder(
  animation: _controller,
  builder: (context, child) {
    final angle = _controller.value * 3.1415927;
    final showAnswer = angle > 3.1415927 / 2;
    return Transform(
      transform: Matrix4.identity()
        ..setEntry(3, 2, 0.001)
        ..rotateY(angle),
      alignment: Alignment.center,
      child: showAnswer ? _AnswerCard(riddle) : _RiddleCard(riddle),
    );
  },
)

这个功能做起来不难，但用户反馈很好。很多人猜谜想看答案的“仪式感”，翻卡片这种交互比直接显示答案要有趣得多。如果你想做得更完善，可以加一个“提示”按钮，显示谜底的首字或者字数提示，这比直接全显示更有参与感。

3.3 搜索与随机出题

搜索是这类内容型 App 的刚需。谜语库几千条数据，直接对 riddle、answer、analysis 三个字段做 SQLite 的 LIKE 查询就够用了，没必要上全文搜索引擎：

sql复制SELECT * FROM riddles
WHERE riddle LIKE '%关键词%'
   OR answer LIKE '%关键词%'
   OR analysis LIKE '%关键词%'

在这个表里，LIKE 查询带上首尾通配符虽然有性能损耗，但数据量只有几千条时完全无感。搜索结果的展示有一个小细节：给命中的关键词做高亮。用 TextSpan 拆词拼接即可，注意中文不存在大小写问题，直接按子串匹配就行。如果你后续要加拼音搜索，那才是真正的复杂度来源，需要给每条谜语单独维护拼音索引字段。

随机出题的逻辑我踩过一个坑**：直接 ORDER BY RANDOM() 虽然简单，但重复率很高，用户点几次就会碰到刚看过的题目。后来我改成了洗牌算法，进入随机出题模块时，对当前分类下的题目索引做一次 Fisher-Yates 洗牌，然后依次出题，一轮出完再重新洗牌，这样既保证随机性又避免短期重复：

dart复制List<int> _shuffledIndexes(List<int> source) {
  final list = List<int>.from(source);
  for (var i = list.length - 1; i > 0; i--) {
    final j = Random().nextInt(i + 1);
    final tmp = list[i];
    list[i] = list[j];
    list[j] = tmp;
  }
  return list;
}

3.4 状态管理架构：Provider 搭配 Repository

状态管理我选了 Provider，没用 Riverpod 也没用 Bloc。原因是这个项目体量不算大，Provider 的学习成本最低，写起来直观，配合 ChangeNotifier 足够处理收藏和筛选这些状态同步需求了。项目分了三层：

• data/ 层：本地 JSON 加载、数据库 DAO。
• repository/ 层：负责封装数据来源，UI 不关心数据是来自内存还是数据库。
• ui/ 层：页面和组件，只通过 Provider.of 或 Consumer 取数据。

一个简单示例，收藏夹的状态管理：

dart复制class FavoritesModel extends ChangeNotifier {
  final Set<int> _ids = {};

  bool isFavorite(int id) => _ids.contains(id);

  void toggle(int id) {
    if (!_ids.add(id)) {
      _ids.remove(id);
    }
    notifyListeners();
  }
}

这样的结构足够清晰，又不会因为分层过多导致开发效率下降。等以后真有复杂状态流需求，再迁移到 Riverpod 也不迟。

4. 数据持久化与同步：从内置 JSON 到 sqflite 再到后端

4.1 内置数据为什么不直接写死在代码里

有人会问，谜语数据才几百条，直接写成一个 List<Riddle> 不就行了？我开始也是这么干的，后面发现两个问题：一是代码文件会变得特别长，维护困难；二是数据里包含中文标点、引号等特殊字符，还有未来要加图片、音频，写死在代码里完全是给自己埋雷。

更好的做法是把数据放在 assets 目录下，作为独立资源文件。运行时通过 rootBundle.loadString 加载：

dart复制final String jsonString = await rootBundle.loadString('assets/data/riddles.json');
final List<dynamic> data = json.decode(jsonString);

首次启动时把 JSON 解析后批量插入数据库。内置数据的好处是不依赖网络，用户断网也能用，这对内容型应用非常重要。等网络可用时，再去服务端拉更新，这就是后面说的同步方案。

4.2 sqflite 在鸿蒙上的落地与踩坑

本地数据库选型，社区讨论最多的三个方案是 sqflite、drift 和 Isar。Isar 性能好，但它在鸿蒙上原生库的适配还不成熟，我不想替它踩坑。drift 功能强大，但生成代码和编译链复杂，对新手不友好。我最终用了 sqflite 的鸿蒙适配分支，核心 API 和官方版本一致，迁移成本最低。

数据库初始化逻辑：

dart复制import 'package:sqflite/sqflite.dart';

Future<Database> _openDB() async {
  final dbPath = await getDatabasesPath();
  return openDatabase(
    '$dbPath/riddle.db',
    version: 1,
    onCreate: (db, version) async {
      await db.execute('''
        CREATE TABLE riddles(
          id INTEGER PRIMARY KEY,
          category TEXT,
          riddle TEXT,
          answer TEXT,
          analysis TEXT,
          difficulty INTEGER,
          hits INTEGER
        )
      ''');
    },
  );
}

在鸿蒙上适配过程中，我遇到的最大坑是数据库文件路径的差异。Android 上 getDatabasesPath() 返回的是 /data/data/包名/databases，鸿蒙上走的是 ohos 分支对应的路径封装，个别适配版本返回值不带最后的斜杠或者目录权限不一致，导致 openDatabase 报错。解决方式是用 path 包手动拼接：

dart复制final directory = await getDatabasesPath();
final dbPath = p.join(directory, 'riddle.db');

另一个建议是批量插入一定要用事务。500 条数据一条条 insert 得花几秒，包在事务里几乎瞬间完成：

dart复制await db.transaction((txn) async {
  final batch = txn.batch();
  for (final riddle in riddles) {
    batch.insert('riddles', riddle.toMap());
  }
  await batch.commit(noResult: true);
});

4.3 本地数据库与后端同步的设计思路

很多人搜“Flutter 做本地数据库 + 后端同步”，说明大家遇到的问题都一样：本地数据好做，一旦要涉及远程更新，离线优先还是在线优先，增量还是全量，冲突怎么处理，全是学问。

我的方案是离线优先 + 版本号增量同步。服务端维护一个 data_version 字段，客户端每次启动时请求一次版本号，如果本地版本低于服务端版本，就拉取增量数据：

json复制{
  "version": 12,
  "increments": [
    {
      "type": "insert",
      "riddle": { "id": 1101, "category": "字谜", "riddle": "...", "answer": "..." }
    },
    {
      "type": "update",
      "id": 1001,
      "fields": { "hits": 3299 }
    }
  ]
}

客户端请求接口时带上本地版本号，服务端返回该版本之后的增量内容。用户新增的收藏和猜题记录，则通过另一个接口上传。这个方案逻辑简单，也符合谜语这种低频更新内容的场景。如果数据量特别大、并发高，再考虑其他同步协议，但对于小工具型应用，版本号增量同步已经足够可靠。

5. 鸿蒙适配的硬骨头：打包、权限、平台通道

5.1 hap、hsp、har 到底怎么选

很多 Flutter 开发者第一次接触鸿蒙打包，会被 hap、hsp、har 这三个缩写搞蒙。实际区别很好理解：

Flutter 工程的鸿蒙侧本质上是一个原生壳工程，最终构建产物就是 hap。使用 DevEco Studio 打开 ohos 目录，配置好签名后，点击 Build 就能生成 entry-default-signed.hap。这里要提醒一句：签名证书的配置和 Android 的很不一样。鸿蒙要求使用 AC 签名工具为 HAP 签名，或者通过 DevEco 的自动化签名功能，配置完证书文件后，在 build-profile.json5 里指定好签名信息。

打包过程还有一个容易踩的坑：版本号需要同步维护。Flutter 工程根目录的 pubspec.yaml 里 version 字段和鸿蒙工程的 app.json5 / module.json5 里的版本号不是自动联动的。我第一版发布时忘了升级鸿蒙侧版本号，导致用户手机上一直检测不到更新。

5.2 通过 MethodChannel 调起鸿蒙原生能力

谜语卡片我加了一个“保存分享”功能，用户可以把谜语内容生成一张精美的卡片图，保存到相册或者分享给好友。Flutter 侧没有直接保存图片到鸿蒙相册的能力，这就需要平台通道。

Flutter 侧 Dart 代码：

dart复制const platformChannel = MethodChannel('com.example.riddle/gallery');

Future<void> saveCardToGallery(Uint8List imageBytes) async {
  try {
    await platformChannel.invokeMethod(
      'saveImage',
      {'bytes': imageBytes, 'filename': 'riddle_card_${DateTime.now().millisecondsSinceEpoch}.png'},
    );
  } on PlatformException catch (e) {
    debugPrint('保存失败: ${e.message}');
  }
}

鸿蒙侧需要在其对应能力入口处监听并实现该方法。ArkTS 侧的代码大致逻辑是：

typescript复制import { photoAccessHelper } from '@kit.MediaLibraryKit';

async saveImageToGallery(bytes: Uint8Array, fileName: string): Promise<void> {
  const helper = photoAccessHelper.getPhotoAccessHelper();
  const uri = await helper.createAsset(photoAccessHelper.PhotoType.IMAGE, 'png', fileName);
  // 打开文件写入字节流，关闭文件
}

这部分耗时主要花在处理图片字节流和相册权限的沙箱访问规则上。鸿蒙的媒体库访问有严格的沙箱限制，写入相册 需要通过 photoAccessHelper 的合规接口，不能直接用绝对路径访问文件。配好权限之后，实测稳定。

权限声明在 entry/src/main/module.json5 里增加：

json复制{
  "requestPermissions": [
    {
      "name": "ohos.permission.READ_IMAGEVIDEO",
      "reason": "用于保存谜语卡片到相册",
      "usedScene": {
        "abilities": ["EntryAbility"],
        "when": "inuse"
      }
    },
    {
      "name": "ohos.permission.WRITE_IMAGEVIDEO",
      "reason": "用于保存谜语卡片到相册",
      "usedScene": {
        "abilities": ["EntryAbility"],
        "when": "inuse"
      }
    }
  ]
}

这里提醒一点**：鸿蒙权限弹窗对“用途说明”审核很严格，reason 字段要写真实、具体的用途**，不能糊弄，否则上架审核可能会被打回。

5.3 沙箱与调试：在 DevEco 里打断点的正确姿势

鸿蒙侧的调试流程和安卓类似，但有几个细节不同。利用 DevEco Studio 打开 ohos 目录，可以直接在 ArkTS 源码里打断点，运行应用后通过模拟器或真机调试。Flutter 侧的 Dart 代码调试则通过 Flutter DevTools 进行，比如打断点看变量、查看 Widget 树等。两条链路互不干扰，但容易搞混。

我自己遇到的一个典型问题：在 DevEco 里对一个 ArkTS 方法打了断点，同时 Flutter 侧也在调同一功能，结果 DevEco 断点一直没触发，后来发现是因为应用的入口流程是 Flutter 先启动，再通过平台通道调用到 ArkTS，必须达到触发操作才会进入对应中断逻辑。要先在 Dart 侧确认日志输出，再去看 ArkTS 侧的断点是不是对应到正确的函数和线程。

日志过滤也值得提一下：HarmonyOS 控制台默认日志非常冗长，我建议在过滤栏固定几个关键词——Flutter 侧的日志可以加统一前缀比如 [riddle]，Native 侧的日志搜索 your package name 或者 EntryAbility，能少翻很多页。

6. 性能与包体：小 App 也要有的自觉

6.1 首次启动速度从 2 秒降到 0.8 秒

内容型小工具很容易被忽视性能，但用户感知最强的其实就是启动速度。我第一版在 main() 里同步加载 JSON 并逐条插入数据库，冷启动要 2 秒多，页面一直白屏。后面做了三处优化：

把数据库导入放到异步 isolate 执行。Isolate.run 在 Dart 里可以很方便地启动一个后台线程处理解析和插入任务，不阻塞 UI 线程：

dart复制final List<Riddle> riddles = await Isolate.run(() async {
  final jsonString = await rootBundle.loadString('assets/data/riddles.json');
  final data = json.decode(jsonString) as List<dynamic>;
  return data.map((e) => Riddle.fromJson(e as Map<String, dynamic>)).toList();
});

先显示骨架屏再刷新列表。首帧不要等着数据加载完，先渲染一个骨架图，等数据流过来后自动替换成真实列表。这个在体验上提升很明显，用户会觉得启动“变快了”。

数据库版本迁移做好预判。后续如果改表结构，要通过 onUpgrade 处理，不能只在开发阶段删库重建。一旦上线，用户的旧数据可能就没了，这类问题对内容型应用打击很大。

6.2 谜语库体积优化：JSON 压缩与字段精简

内置 JSON 文件我一开始写得很“规整”，缩进两格、字段全名，500 条数据下来居然有 300 多 KB。做跨平台发布时，这个体积虽然不算大，但还是有优化空间。我把 JSON 做了三步瘦身：去掉所有无用空格，字段名缩写（rh 代替 riddle，aw 代替 answer），解析的时候再做映射；再配合 gzip 压缩，最终体积只有原来的三分之一不到。不过这种做法有一个代价：可维护性下降，所以我建议你在开发阶段保留完整 JSON，发布前再跑一次压缩脚本，不要直接压缩源文件。

后续如果要加大谜语库，也可以直接把 SQLite 数据库文件放进 assets 里，首次启动时 copy 到应用私有目录，省去解析和逐条插入的步骤，启动速度还能再快一点。这个方案对几百 MB 级别的数据量更适用。

6.3 一个加分项：无图“谜语卡片”的生成

当前版本的“保存分享”功能里，原本计划配背景图，但为了控制包体，我最终选择用 CustomPaint 在 Canvas 上绘制卡片。这样用户拿到的是纯矢量绘制的卡片图，既清晰又不用内置一堆图片资源，包体增量几乎为零。

绘制谜语卡片的核心是叠加文本和简单图形：背景色块、标题、谜面、谜底、解析，文字多了要换行，就得用 TextPainter 手动布局。这部分代码不复杂，但考细心，特别是对齐和边距。我分享一个小经验：先固定卡片宽高，再在里面按比例分配文字区域，不要根据文字长短去动态算卡片高度，否则生成几百张卡片很容易出现尺寸不一致的问题。

卡片生成后调用上一节说的平台通道保存到相册，整个功能的用户体验闭环就完整了。

7. 最后再分享几点我的真实体会

这个谜语大全项目做到后面，我最大的体会是：做跨平台鸿蒙开发，心态上要接受“版本迭代快、文档分散”的现实。Flutter 官方文档不会写鸿蒙怎么适配，鸿蒙社区文档里 Flutter 相关的内容也不多，很多问题要靠自己搜、自己试。我建议准备入坑的朋友先做好三个心理准备：

不要指望所有 Flutter 插件在鸿蒙上都能直接用。任何插件都要注意它的原生实现是否包含鸿蒙适配。官方插件列表里很多插件已经有 ohos 分支，但用之前先看仓库的 issue。

版本锁定的习惯要养成。给项目做环境依赖清单，记下 DevEco、Flutter SDK、JDK 的版本号，否则半年后回来维护项目，你可能连为什么当初用这个版本都想不起来。

从“能用”开始，把精力放在用户能感知的地方。我这个谜语大全没有用多么高深的技术，核心功能都是 Flutter 基础组件加少量平台通道，但用户不会关心你用的是 Provider 还是 Bloc，他们关心的是猜谜顺不顺手、卡片好不好看、分享快不快。技术只是手段，把产品体验打磨好，才是这个项目让我最满意的地方。

如果你也正在用 Flutter 做鸿蒙适配，希望这篇笔记能帮你少踩几个坑。做完之后的下一步，我准备把谜语库扩充到 2000 条，再把每日推荐和猜题打卡加上，到时候有新的坑再回来写一篇。