Flutter跨平台开发鸿蒙应用：电影推荐Demo实战与避坑指南

最近在折腾Flutter框架的跨平台能力时，我被绕了一大圈之后才弄明白：同一套Flutter代码，能不能真正落到鸿蒙系统上？正好手上有一个电影推荐APP的想法，索性直接做成Demo，跑通了从环境搭建、页面开发到鸿蒙真机安装的完整流程。这个项目没有用到复杂的云端架构，核心就是“一套Dart代码，多端显示”，但在鸿蒙侧踩出来的坑，确实比单纯做Android或iOS要多出好几倍。这篇文章就围绕这个电影推荐Demo，把整体设计、环境搭建、关键页面实现、真机打包和常见问题全部分享出来，适合那些准备在鸿蒙开发中引入Flutter，但又不想一上来就啃大段源码的开发者。

1. 先想清楚再动手——电影推荐APP在鸿蒙上的整体设计

1.1 为什么选Flutter，而不是其他跨平台方案

在鸿蒙上做跨平台开发，第一反应是“直接写鸿蒙原生不就好了？”这话对只做一个端的场景成立。但如果是现有团队已经积累了Flutter代码，或者产品需要同时交付iOS、Android和鸿蒙三端，那跨平台框架的价值就出来了。我选择Flutter，核心原因是它的渲染机制：UI不是依赖系统原生控件，而是由Flutter引擎自己绘制。这就意味着，只要Flutter引擎能在鸿蒙上被跑起来，页面呈现的视觉和交互逻辑就可以做到高度一致，不需要像其他方案那样为鸿蒙重写大量原生控件。

对比来看，React Native这类依赖原生控件的跨平台框架，在鸿蒙上需要维护一整套原生控件的映射，工作量和稳定性风险都更高；而轻量级的WebView套壳方案虽然简单，但交互体验和离线能力都跟不上。Flutter的折衷点在于：它牺牲了一点点对系统原生控件的依赖，换来了最大限度的渲染一致性。鸿蒙侧的Flutter引擎已经有人在做持续适配，虽然不能直接当作官方稳定版本用，但跑通常规页面、动画、滚动列表完全可行。

这个决策背后还有一个现实考量：电影推荐APP的页面以图片列表、卡片、评分交互为主，对UI一致性要求高，对系统底层API的依赖比较少。把复杂的系统能力放原生侧，把业务和UI放Flutter侧，刚好能避开当前鸿蒙适配场景里的短板。所以整体的技术路线在动手之前就已经明确：Flutter负责跨端业务逻辑和UI，鸿蒙原生负责项目外壳、系统能力和签名打包。

1.2 电影推荐APP的功能定位与页面架构

这个Demo的定位不是做一个商业级产品，而是验证一条完整的开发链路：从数据获取、推荐排序、用户交互，一直到鸿蒙上的安装运行。功能被刻意控制在五个核心模块里：首页推荐流、电影详情、评分、收藏和“更多推荐”列表。这样既能把Flutter跨端能力展示出来，又不至于让项目失去控制。

页面划分上，我做了三屏结构。首页是推荐的电影卡片流，用户滑动浏览，卡片上直接展示海报、标题、标签和评分；点击卡片进入详情页，详情页里可以评分、收藏，同时根据当前电影的标签推荐三部相似影片；收藏页负责汇总用户标记过的电影，并按收藏时间排列。整体看下来，三个页面已经覆盖了电影类APP最常用的闭环，也足够用来验证导航、状态管理和本地数据持久化。

页面与核心组件的关系可以参考下面这张表：

这个结构在鸿蒙上完全是Flutter侧的自绘页面，不需要针对鸿蒙重新布局。真机验证时，我发现字体和圆角这类视觉细节，比原生页面更容易保持一致，这也是自绘引擎带来的直观收益。

1.3 技术选型与依赖清单

技术选型围绕“尽量少给鸿蒙适配增加负担”来定。状态管理采用Provider，理由是它只依赖Dart层，不碰系统控件，而且ChangeNotifier的写法很容易理解。网络请求采用dio，因为项目后续要切换到远程接口，dio的拦截器、取消请求、超时控制都比较顺手。本地持久化用shared_preferences，电影推荐场景只需要保存几个JSON字符串，完全够用。图片加载用cached_network_image，它能缓存网络图片，避免在卡片流里频繁重复请求。

不过这里有个非常关键的前提：所有第三方依赖都要确认能在鸿蒙适配分支上正常工作。第三方包如果依赖了Android或iOS原生插件，鸿蒙侧如果没有对应实现，编译时不会报错，运行时会直接闪退或功能缺失。所以我在项目初期只引入了上面几个纯Dart层插件或已有鸿蒙适配的插件，其余能自己实现的绝不多加依赖。

依赖清单可以按下表参考：

版本选择上我的建议是：不要追新。鸿蒙适配分支往往滞后于Flutter官方版本，如果你用了太新的Dart语法，或者引入了太新的依赖，最终return的可能是一堆编译错误。锁定一个稳定组合，比什么都要重要。

2. 搭建鸿蒙上的Flutter开发环境

2.1 环境准备

开始之前，先把工具链准备好。我本机环境是Windows，但这套流程在macOS上类似，只是环境变量和路径会稍有变化。需要准备四样东西：鸿蒙开发者工具、鸿蒙SDK、Flutter的鸿蒙适配分支、以及JDK。我建议先把鸿蒙开发者工具安装好，因为它会自动带上一套匹配的鸿蒙SDK，后续只需要在IDE里确认SDK路径。

第一次启动IDE时，SDK管理界面会提示是否下载SDK。建议把API版本和工具链都勾上，尤其是构建工具和SDK组件，缺少任何一个，后面编译的时候都会报“组件缺失”。下载SDK其实没什么技巧，耐心等完就行。比较推荐的做法是同时把模拟器也装好，因为真机调试之前，先用模拟器跑通流程能省下很多排队等待的时间。

准备Flutter的鸿蒙适配分支也需要提前做。我一开始图省事，直接使用官方Flutter稳定版，结果构建鸿蒙包的时候直接提示找不到鸿蒙目标平台。这个坑在社区里很常见。Flutter官方版本目前只内置了Android和iOS等平台，鸿蒙作为一个新系统平台，需要用到专门的适配分支。把本机Flutter替换成适配分支之后，flutter命令才会多出鸿蒙相关的构建能力。

环境准备的操作步骤可以整理成这样：

1. 安装鸿蒙IDE，完成基础配置。
2. 安装鸿蒙SDK和模拟器镜像。
3. 下载或克隆Flutter的鸿蒙适配分支。
4. 将适配分支的bin目录加入PATH环境变量。
5. 在IDE里设置SDK路径，确认flutter能识别到鸿蒙SDK。

2.2 获取适配鸿蒙的Flutter引擎分支

这一步是整个项目能否继续的地基。Flutter本身是一个跨平台引擎，但鸿蒙不是它原生支持的目标平台，所以需要找到维护鸿蒙适配的引擎分支。常见做法是从适配分支的发布页直接下载压缩包，解压到本地，然后把它当作普通的Flutter SDK来用。也可以用Git克隆分支，我习惯用这种方式，因为后续想查看引擎源码时更方便。

克隆完成后，需要把bin目录配置到全局PATH。在Windows上，打开系统环境变量，把类似C:\flutter_harmonyos\bin追加到PATH前面；在macOS或Linux上，直接写到shell配置文件的export语句里。配置完成之后，在终端执行flutter doctor，如果一切正常，你应该能在诊断信息里看到鸿蒙相关工具链的状态，至少不会像官方版那样只强调Android和iOS。

这里必须强调一个细节：以后所有Flutter项目都编译在这个分支下，不要在你的项目目录里手动混合两个版本的Flutter SDK。我之前试过用官方版创建工程，再切到鸿蒙分支构建，结果flutter create生成的平台目录里根本没有鸿蒙目录，后面只能重新创建工程。最稳妥的做法是一开始就用适配分支创建项目，让项目的平台结构从一开始就包含鸿蒙。

2.3 创建混合工程并打通原生入口

拿到适配分支后，创建工程的方式和普通Flutter工程没有本质区别，唯一区别是flutter create时平台参数要加上鸿蒙目标。命令大致长这样：

flutter create --platforms=ohos,android,ios movie_recommend_demo

执行完成后，工程根目录下会多出一个ohos目录，这就是鸿蒙的原生壳工程。接下来需要用鸿蒙IDE打开这个ohos目录，或者打开整个Flutter工程并在IDE中识别它。此时会看到鸿蒙原生侧有一个入口模块，这个模块相当于一个小容器，Flutter引擎会把绘制结果渲染到这个容器里。

原理解释一下：你在Flutter侧写的所有页面、动画、手势，最终都是Flutter引擎自己绘制完成的，鸿蒙原生侧只负责提供一个窗口、把屏幕触摸事件传给Flutter引擎、把引擎渲染出的画面呈现出来。所以打通原生入口的关键，就是让鸿蒙模块初始化Flutter引擎，并加载Dart代码生成的产物。IDE通常会自动关联，但如果你用的鸿蒙IDE版本较老，可能需要手动添加原生依赖，把Flutter引擎作为原生模块引入。

打通入口之后，我建议先在原生壳里放一个仅供验证用的按钮或页面，确保鸿蒙壳本身没问题，再开始写Flutter侧的业务代码。这能帮你把“原生壳问题”和“Flutter问题”隔离开，排查时思路会清晰很多。

2.4 验证最小Demo能跑起来

第一步验证的目标只有一个：让Flutter默认计数器页面跑在鸿蒙模拟器上。直接连接模拟器，然后在终端执行：

flutter run -d ohos

如果一切顺利，你会看到IDE先执行编译，再打包，最后把应用安装到模拟器上。第一次构建的时间会稍微长一点，因为引擎的鸿蒙适配层也需要参与编译。这个等待过程十分正常，不用一看到长时间没反应就以为卡死了。

默认计数器页面能在模拟器上点击并递增数字之后，说明环境链路已经通了。接下来我会在这个基础上把工程清空，替换成电影推荐Demo。这里还有一个小建议：换成真机之前，先做一次flutter build hap --debug或通过IDE构建hap包，确认打包流程没问题。模拟器能跑不代表真机能装，签名和安装权限是另一套问题，留到后面统一处理。

3. 电影推荐APP的核心细节解析与实操要点

3.1 数据层：接口封装与本地缓存

干净的数据层，能让后续换接口时少动UI。我在项目里定义了一个Movie模型，包含电影ID、标题、海报地址、标签列表、评分和简介几个字段。Dart类写起来很直接：

class Movie { final String id; final String title; final String posterUrl; final List<String> tags; final double rating; final String summary; Movie({ required this.id, required this.title, required this.posterUrl, required this.tags, required this.rating, required this.summary, }); factory Movie.fromJson(Map<String, dynamic> json) { return Movie( id: json['id'] as String, title: json['title'] as String, posterUrl: json['posterUrl'] as String, tags: List<String>.from(json['tags'] as List), rating: (json['rating'] as num).toDouble(), summary: json['summary'] as String, ); } Map<String, dynamic> toJson() { return { 'id': id, 'title': title, 'posterUrl': posterUrl, 'tags': tags, 'rating': rating, 'summary': summary, }; } }

数据源层面，我定义了一个抽象接口MovieDataSource，只暴露一个方法：Future<List<Movie>> fetchMovies()。第一个实现是LocalDataSource，从本地JSON文件读取种子数据，这样Demo在没有服务器的时候也能跑；第二个实现是RemoteDataSource，用dio请求远程接口并解析成电影列表。UI层只依赖抽象接口，所以切换数据源时不改页面代码。

这里还有一个容易被忽略的实操点：启动时读取本地缓存的速度非常快，但如果缓存里已经有旧数据，直接用旧数据渲染会让用户看到过期内容。我在Demo里的做法是，先展示缓存数据，再后台请求远程接口，接口返回成功后更新列表并重写缓存。这看起来是很常规的做法，但它对体验的提升非常明显，尤其是在鸿蒙模拟器网络不稳定的场景下，至少不会白屏。

3.2 推荐算法：简单但有效的标签权重方案

电影推荐如果直接用协同过滤，数据量不够时效果反而很弱。我采用的是标签权重打分方案，思路非常简单：用户每对一部电影做出正向反馈，比如收藏或给出高于3分的评分，就把这部电影的标签累加到用户偏好向量里。推荐候选电影时，用它包含的标签去匹配用户偏好向量，匹配分越高，排序越靠前。

代码上维护一个Map<String, double> userProfile，key是标签名，value是权重。这个映射在状态管理类里维护，每次收藏/评分都会触发更新。排序前，先每部候选电影算分，再把所有电影按分值降序排列。打分逻辑的核心就几行：

double _scoreMovie(Movie movie, Map<String, double> userProfile) { double score = 0; for (final tag in movie.tags) { score += userProfile[tag] ?? 0; } return score; }

为了让结果更自然，我会在基础分上再加一点热度分。热度分可以来自电影本身的评分，或者预设的播放量数据。但要注意，热度分权重不能盖过用户偏好，否则用户看来看去都是排行榜上的热门片，推荐就失去了个性化。在Demo里，热度分的权重只占0.2，用户标签匹配分占0.8。这个比例是我手动调出来的，具体项目可以根据实际反馈重新调整。

这个方案虽然简单，但已经能产生“看过一个科幻片，首页就会多推科幻片”的可感知效果。它最大的优点是完全在Dart层实现，不依赖任何鸿蒙或Android原生能力，所以跨端一致性非常好。

3.3 UI层：卡片式推荐流的实现

首页的推荐流是电影推荐APP最重要的门面。我使用ListView.builder做长列表，每个item是一张电影卡片。卡片结构从左到右依次是海报缩略图、电影信息和右侧的收藏按钮；下部是标签行和评分。卡片之间用间距分开，整体背景做成深色，这样海报图片的对比度会更高，具体界面看起来也会更像一个观影产品。

电影卡片的核心实现可以概括为：

Widget _buildCard(BuildContext context, Movie movie) { return Card( clipBehavior: Clip.antiAlias, child: InkWell( onTap: () => Navigator.push( context, MaterialPageRoute(builder: (_) => MovieDetailPage(movieId: movie.id)), ), child: Padding( padding: EdgeInsets.all(12), child: Row( children: [ Image.network( movie.posterUrl, width: 80, height: 120, fit: BoxFit.cover, errorBuilder: (_, __, ___) => Container( color: Colors.grey[800], child: Icon(Icons.movie), ), ), SizedBox(width: 12), Expanded( child: Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ Text(movie.title, style: TextStyle(fontSize: 18, fontWeight: FontWeight.bold)), Wrap( spacing: 6, children: movie.tags .map((tag) => Chip(label: Text(tag), materialTapTargetSize: MaterialTapTargetSize.shrinkWrap)) .toList(), ), Text('评分：${movie.rating.toStringAsFixed(1)}'), ], ), ), IconButton( icon: Icon(isFavorite ? Icons.favorite : Icons.favorite_border), onPressed: () => context.read<RecommendationModel>().toggleFavorite(movie.id), ), ], ), ), ), ); }

这里有几个UI细节值得说。第一，海报图片必须提供errorBuilder。推荐流里图片一旦有一张挂掉，占位容器如果没做，整个卡片的高度会塌掉，列表顺序就会跳动。第二，标签用Wrap而不是Row，因为电影标签个数不固定，超过屏幕宽度时自动换行会更稳。第三，收藏按钮的点击区域要足够大，但卡片上的InkWell会导致按钮点击时出现双层水波纹，所以我会把收藏按钮单独包一层，避免和卡片的点击手势冲突。

3.4 状态管理：从setState到Provider的决策过程

最开始图省事，所有页面直接setState，结果写了几个页面之后发现回调传参很乱。比如收藏页要同步首页的收藏状态，详情页评分之后还要回到首页重新加载列表，这种跨页面的数据同步，用setState真的会写到崩溃。

后来我把状态提升到一个全局的RecommendationModel里，用Provider做依赖注入。这个Model继承了ChangeNotifier，里面维护电影列表、收藏ID列表、用户标签偏好和当前推荐顺序。任何页面通过context.read<RecommendationModel>()拿引用，修改状态后调用notifyListeners()，UI自动重建。

选择Provider而不是其他方案，主要是因为它足够轻。在鸿蒙适配分支上，第三方状态管理库如果依赖原生能力，反而会增加适配风险。Provider的依赖只在Dart层，不会去碰原生控件，所以它能直接跟随Flutter引擎在鸿蒙上跑。真机验证下来，Provider的刷新频率和UI重建都没有异常，这个项目用它完全够。

4. 实操过程：关键环节的完整实现

4.1 首页推荐流的页面代码实现

先搭建一个最基础的首页。首页在启动时会从Model里异步加载数据，通过Consumer监听状态变化。完整页面结构大概是这样：

class HomePage extends StatelessWidget { const HomePage({super.key}); @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar(title: const Text('电影推荐')), body: Consumer<RecommendationModel>( builder: (context, model, child) { if (model.isLoading && model.movies.isEmpty) { return const Center(child: CircularProgressIndicator()); } if (model.movies.isEmpty) { return const Center(child: Text('暂时没有可推荐的电影')); } return ListView.builder( padding: const EdgeInsets.all(12), itemCount: model.movies.length, itemBuilder: (context, index) { final movie = model.movies[index]; return MovieCard(movie: movie, isFavorite: model.isFavorite(movie.id)); }, ); }, ), ); } }

这里有一个很重要的小细节：model.isLoading && model.movies.isEmpty这个条件，是为了区分“首次加载”和“刷新数据”。如果数据已经在缓存里，加载远程接口时不应该把整个页面换成加载转圈，否则用户每次进首页都会闪一下白屏。鸿蒙模拟器上可能不明显，但真机和低配设备上，这个闪烁会被放大。

MovieCard组件我切成单独一个文件，里面接收电影对象和收藏状态，不直接依赖全局Model。这样做的理由是，卡片在列表里会频繁重建，让它保持“哑组件”身份，只根据传入参数渲染，内存和刷新成本都更低。

4.2 评分与收藏功能的联动

评分和收藏是推荐算法的输入，所以这两个功能不是孤立存在的。详情页里用户给某部电影打了5分，这个信号要能改变后续的首页推荐顺序。

我在Model里设计了三个核心方法。toggleFavorite负责切换收藏状态；updateRating负责更新评分；二者都会触发_applyUserPreference来更新标签偏好，然后重新计算推荐列表。

void toggleFavorite(String movieId) { if (_favoriteIds.contains(movieId)) { _favoriteIds.remove(movieId); _subtractPreference(movieId); } else { _favoriteIds.add(movieId); _addPreference(movieId); } notifyListeners(); _reorderRecommendations(); }

评分联动逻辑类似，但评分是连续的，所以更加细腻：3分以下不增加权重，3分以上按分数线性增加。这个阈值来自一个很朴素的产品假设：用户愿意给高分，意味着他喜欢这类标签；给低分，说明他不喜欢。

这里踩过的一个坑是，每次调用_reorderRecommendations都会创建一个新的排序列表，而用户连续滑动时如果频繁触发评分和收藏，列表会反复重建，导致卡片跳动。解决方法是做一次防抖，收藏和评分的触发频率都不高，但在真实使用中仍要注意。我最终在_reorderRecommendations里加了300毫秒的延迟，只有用户停止操作后才做最终排序。

4.3 鸿蒙打包与真机调试实录

功能都写在Flutter侧之后，真正的考验才开始：把它变成一个能在鸿蒙真机上安装的hap包。我先在鸿蒙IDE里打开ohos目录，然后配置签名。对个人开发者来说，最方便的是使用IDE的自动签名能力，它会自动创建调试证书和Profile，并把当前设备的标识加到允许列表里。

签好名之后，可以在IDE里直接选择构建产物，也可以回到命令行执行flutter build hap --release。我试过两种方式，IDE构建更适合排查编译错误，命令行更适合集成到持续集成流程。Release包构建完成后，会在工程目录下生成一个hap文件，接下来连上真机，开启开发者模式，通过IDE的安装工具把这个hap推送到设备上。

第一次真机安装时，应用启动比模拟器慢一些，这是因为Release包首次启动时要做一些引擎初始化。启动完成后，首页的卡片流滚动很流畅，评分和收藏的点击响应也没有明显延迟。整个过程说明，用Flutter在鸿蒙上做电影推荐类的交互页面，性能上是可行的。

4.4 性能优化：检查内存泄漏与滑动流畅度

做完功能后，我用IDE自带的性能分析工具看了一下首页的GPU和内存曲线。主要观察两个点：一个是滑动列表时是否持续掉帧，另一个是内存是否只涨不降。

如果出现卡片在滑动过程中闪烁或掉帧，优先检查图片加载。cached_network_image本身有缓存，但我发现当海报图尺寸太大时，解码耗时依然很高。解决办法是让后端或数据源提供按宽度裁剪的缩略图，Demo里则手动限制海报宽度为200像素左右。这个优化虽然小，但效果显著。

内存泄漏方面，最容易出问题的是一些异步回调没有取消。比如页面已经退出，网络请求才返回，这种情况下如果不判断组件是否仍在树中，Model回调就会指向已经不存在的页面。我的做法是在所有需要取消请求的地方使用异步辅助工具，或者在State的dispose阶段置一个_isDisposed标志，回调里先判断再更新UI。这个习惯在鸿蒙上同样适用，真机长时间滑动后，内存曲线会比不做处理平稳很多。

5. 常见问题与排查技巧实录

5.1 编译报错“找不到鸿蒙引擎”

这个报错几乎每个初上手的人都会遇到。现象是命令行构建时提示找不到鸿蒙SDK或者OHOS相关路径。原因通常是IDE的SDK路径没有传递给Flutter适配分支。

解决方法是在工程根目录下维护一个配置文件，把SDK路径写进去。配置内容大致是：

ohos.sdk.dir=/path/to/your/harmonyos/sdk

写完配置后重启IDE，再执行flutter doctor确认鸿蒙工具链能识别。如果仍然报错，检查环境变量里是否残留了旧版Flutter的指向。把旧版Flutter从PATH里挪掉，确保终端输入flutter --version时是鸿蒙适配分支，这个根因就能排除一大半。

5.2 中文乱码与字体适配

我在鸿蒙模拟器上碰到过一次比较尴尬的情况：英文和数字显示正常，中文标题全部变成方块。罪魁祸首是鸿蒙适配分支在渲染中文时，默认字体回退不完整。这个现象在Android上不容易出现，因为系统里预装了大量中文字体，但鸿蒙适配分支不能完全依赖系统字体。

解决办法有两种。第一种是在MaterialApp的主题里显式设置字体family，让Flutter优先使用自带或项目打包的中文字体；第二种是把一个中文字体文件放进assets，并在pubspec.yaml里声明。Demo里我采用的是第二种，因为字体的视觉一致性更好。这一步看着小，但如果没做好，整个APP的中文界面会非常影响观感。

5.3 网络请求在鸿蒙上失败

因为Demo一开始用本地数据，我直到后期才接入远程接口，结果一接入就在鸿蒙模拟器上遇到超时。排查下来有两个原因。第一，鸿蒙应用默认没有网络权限，必须在原生侧配置文件里声明网络权限；第二，如果接口是http明文地址，在部分调试模式下会被直接拒掉。

解决办法是在鸿蒙模块的配置里补上网络权限声明，并把调试环境的接口地址改成https。如果后端暂时没有https证书，本地调试可以临时开启明文流量，但正式包一定不要这么干。对Demo来说，最保险的方式还是以本地种子数据跑通主要链路，远程接口后续再按需调整。

5.4 真机无法安装/签名问题

最让人头疼的问题是：模拟器上跑得好好的，真机却提示安装失败或签名校验失败。这通常是签名信息不对造成的。鸿蒙真机要求hap包必须使用包含当前设备标识的调试证书签名，自动签名只对勾选过的设备生效。

解决办法是回到IDE，打开签名配置，重新生成自动签名，并确保当前真机已经被连接并被识别。如果设备之前被移除，需要重新添加设备标识，再重新构建hap。这里的一个重要提示是，每次更换调试设备都要重新签名，别拿上一台机器的包往新设备上硬塞。

5.5 避坑速查表

这张表是我在完整跑完项目之后整理出来的，基本覆盖了新人在鸿蒙上遇到的主要问题。如果你按照这个顺序排查，绝大多数情况都能快速定位。

6. 最后说点个人体会

这个项目做完之后，我对Flutter跨平台和鸿蒙开发都有了新的认识。先说结论：Flutter在鸿蒙上跑通业务是能做到的，但前提是别对“开箱即用”抱有期待。鸿蒙侧的适配分支还在快速迭代，我建议把项目运行关键依赖的版本固定住，不要因为看到新版本就盲目升级；每次升级都可能带来引擎行为的变化，升级前先在最小工程里验证。

还有一个很深的体会是，做鸿蒙适配时，问题排查一定要学会“切分”。遇到报错，先确认是鸿蒙原生壳的问题，还是Flutter层的问题，还是数据层的问题。别一上来就翻页面代码。我这次很多时间其实花在了环境配置和签名上，真正写页面逻辑只占了一小部分。如果你也能把环境调试和业务开发分开，项目推进起来会顺很多。

最后分享一个小技巧：遇到鸿蒙上诡异的显示或运行问题时，先建一个最小还原Demo。把一个列表、一个网络请求、一个字体页面分别拆出来验证，定位到具体现象再回到完整项目里修。这比在完整APP里盲猜要高效得多。电影推荐APP只是个起点，后面还有缓存策略、离线推荐、推送这些可以继续扩展，先把地基打牢，后面的路才好走。