企业官网建设流程全解析

这个系列写到现在，播放器内核、首页推荐、歌单详情其实都已经过了一遍。第13期为什么单独拎出歌手列表来做，因为它在音乐App里是一个看似简单、实际很容易做得粗糙的模块。很多人第一反应是“歌手列表不就是头像加名字排一排嘛”，但真做起来就会发现，数据怎么建模、头像裁切怎么做、字母索引怎么联动、点击之后怎么把歌手对象安全传到下一个页面，每一项都有讲究。尤其是在 Flutter for OpenHarmony 这个组合下面，虽然Flutter的UI框架本身跨端一致，但底层像素、字体渲染、图片加载策略都跟Android/iOS上有差异，不能想当然。这篇文章会把歌手列表从数据模型到UI、从路由跳转到OpenHarmony适配的完整链路拆开讲，按你直接抄作业的标准来写。

1. 歌手列表在音乐App里到底承担什么角色

1.1 为什么这几期要把歌手列表单独拿出来做

音乐播放器的用户路径往往不是单一的。用户可能打开首页点推荐歌单，也可能进搜索页找某首歌，还可能顺着“最近播放”继续听。歌手列表是所有这些路径里一个频繁出现但又容易被忽视的入口。用户在听某首歌的时候，大概率会点一下歌手名字进去看看这位歌手还有哪些作品，所以歌手列表页不仅要长得好看，还要能承载后续的跳转，它是歌手维度内容的一个导航中枢。

从整个App的结构看，我的项目里歌手列表并不是孤立页面，它承担了三个职责：第一，展示歌手的基本信息和作品规模，让用户对歌手有个总览印象；第二，把用户引导到歌手详情页，这一步要传递干净的歌手模型对象，不能靠拼字符串当参数；第三，在一些首页推荐模块里，歌手卡片和歌手列表页还会互跳，所以页面级的跳转参数协议需要提前定好，不然后面做首页聚合时又要返工。

1.2 前后模块的耦合关系

我这次实现前先捋了一下已经完成的页面：首页推荐、歌单详情、播放页、搜索页。搜索页里有一个搜索结果会展示歌手，歌单详情里每一首歌也带歌手信息，播放页的歌曲信息栏同样需要点击歌手跳详情。如果不提前建一个统一的歌手模块，这几个地方可能会各写各的跳转逻辑，到时候数据格式不统一，排查起来会非常痛苦。

所以这一期写的歌手列表，本质上是把“歌手”这个实体在全局范围内规范化一次。先把歌手模型定下来，再把列表页、详情页的路由通道打通，之后首页、搜索页、播放页只要复用了这套模型和路由规则，所有入口的点击行为都能保持一致。这就是为什么我在项目里宁可多花一点时间做数据层设计，也不在前面抢着堆UI。

1.3 适合谁来参考

如果你在做一个Flutter项目，并且要往OpenHarmony设备上跑，这一期的参考价值会比较大。当然纯做Android/iOS的读者也能看，大部分代码是跨端通用的。建议你已经至少跑通了一个Flutter页面，对ListView.builder、FutureBuilder这些基础组件有概念，再来读这一期，否则代码里的细节会比较多，容易晕。如果遇到OpenHarmony环境下特有的编译配置问题，可以直接翻到第5章看适配排查部分。

2. 歌手数据模型与列表数据加载设计

2.1 歌手模型字段到底该定哪些

歌手列表显示什么，直接决定模型要写什么字段。我一开始走了个弯路：把歌手模型设计成了“大而全”，把专辑数、歌曲数、粉丝数、简介、头像、背景图全塞进去，结果列表页只需要其中一小部分，详情页又觉得字段不够，最后两头都在改。后来我按照“列表页、详情页、搜索页三端需求交集”来倒推字段，才把模型稳定下来。

class SingerModel { final String id; // 歌手唯一ID，列表页跳详情页传这个就够了 final String name; // 歌手名 final String avatarUrl; // 头像地址 final int songCount; // 歌曲数 final int albumCount; // 专辑数 final String category; // 流派/分类，比如流行、摇滚、民谣 final String description; // 简介，详情页才会用到，列表页可不展示 const SingerModel({ required this.id, required this.name, required this.avatarUrl, this.songCount = 0, this.albumCount = 0, this.category = '', this.description = '', }); factory SingerModel.fromJson(Map<String, dynamic> json) { return SingerModel( id: json['id']?.toString() ?? '', name: json['name']?.toString() ?? '未知歌手', avatarUrl: json['avatarUrl']?.toString() ?? '', songCount: json['songCount'] ?? 0, albumCount: json['albumCount'] ?? 0, category: json['category']?.toString() ?? '', description: json['description']?.toString() ?? '', ); } Map<String, dynamic> toJson() { return { 'id': id, 'name': name, 'avatarUrl': avatarUrl, 'songCount': songCount, 'albumCount': albumCount, 'category': category, 'description': description, }; } }

字段设计的一个关键点是id的数据类型。网上很多接口会把ID返回成数字，但你千万别在Dart里把id定义成int，因为真实的歌手ID很可能超过int范围，而且未来要跟字符串类型的接口做联调，直接用String最稳妥。我在Dart侧做了一层防御性转换，json['id']?.toString()，这样无论上游返回数字还是字符串都能兜底。

2.2 mock数据先行，真实接口后置

我在项目最开始阶段并不要什么服务端去提供歌手数据，通常都是自己写一个mock类，把固定JSON塞进去，保证页面开发不被后端阻塞。但mock数据一旦写得不对，后面切换到真实数据的时候就会出问题。比如我在mock里用了假的图片链接，直接用了本地asset图片，切到线上时发现网络图加载失败，因为OpenHarmony环境下的网络权限和在浏览器里调试时的行为不太一样。

我建议的做法是给数据层做一个抽象接口，页面只依赖这个接口，不直接依赖具体实现。mock和真实接口都实现同一个接口，这样后面切换时页面代码不用动。

abstract class SingerRepository { Future<List<SingerModel>> fetchSingers(); } class MockSingerRepository implements SingerRepository { @override Future<List<SingerModel>> fetchSingers() async { // 模拟网络延迟 await Future.delayed(const Duration(milliseconds: 600)); // 实际开发中把JSON做成模拟数据文件放asset里 return [ SingerModel(id: '1', name: '林晚', avatarUrl: 'assets/images/singer_linwan.png', songCount: 42, albumCount: 8, category: '流行'), SingerModel(id: '2', name: '陈砚', avatarUrl: 'assets/images/singer_chenyan.png', songCount: 68, albumCount: 11, category: '摇滚'), // 更多... ]; } } class ApiSingerRepository implements SingerRepository { @override Future<List<SingerModel>> fetchSingers() async { // 这里写真实的网络请求 final response = await http.get(Uri.parse('https://api.example.com/singers')); final data = jsonDecode(response.body) as List; return data.map((e) => SingerModel.fromJson(e as Map<String, dynamic>)).toList(); } }

这样做的另一个好处是，测试和演示的时候可以直接跑mock版本，不需要纠结后端接口是否稳定。我在模拟项目X里甚至做了一个简单的可选注入，用编译常量控制走哪一个Repository，方便不同环境打包。

2.3 加载状态的细致处理：加载中、空数据、失败重试

歌手列表的加载状态是最容易做秃的。很多人用FutureBuilder就只写了等待和成功两个分支，结果遇到空数据页面白屏、网络错误直接红屏，非常影响体验。我在这个项目里是明确画了三种状态的：加载中显示骨架屏，数据为空显示一个带按钮的占位页，请求失败显示错误提示和重试按钮。

骨架屏不一定要用复杂的第三方库，我自己写了一个简单的灰色圆块加两条灰色矩形，用AnimatedOpacity让透明度循环变化，效果就够用了。空数据的页面也别只写一行字，给一个“暂无歌手”的文案加一个刷新按钮，用户至少知道下一步可以做什么。失败状态同理，关键是按钮点击后要能重新触发加载，你不能把按钮写成一个摆设。

Widget _buildLoadingSkeleton() { return ListView.builder( itemCount: 6, itemBuilder: (context, index) { return Padding( padding: const EdgeInsets.symmetric(horizontal: 16, vertical: 12), child: Row( children: [ Container( width: 56, height: 56, decoration: const BoxDecoration(color: Colors.grey, shape: BoxShape.circle), ), const SizedBox(width: 12), Expanded( child: Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ Container(width: 120, height: 16, color: Colors.grey), const SizedBox(height: 8), Container(width: 200, height: 12, color: Colors.grey), ], ), ), ], ), ); }, ); }

这三个状态做完整之后，用户体验会上升一个档次。尤其OpenHarmony设备上，有些低端机网络加载慢，骨架屏能明显降低等待期的焦虑感，这是我在实际测试中观察到的。

3. 歌手列表页UI实现：卡片布局、字母索引、下拉刷新

3.1 页面结构和状态管理选型

歌手列表页我采用的是比较经典的三段式结构：上方一个固定的搜索框区域，中间是歌手列表主体，右侧浮着A-Z字母索引条。有些App会把字母索引放在列表Header吸顶，但我觉得普通列表页不需要搞那么重，加上右侧索引条已经足够手指操作了。

状态管理方面，这一期没有盲目引入复杂框架。列表页的数据是“拉一次、展示、刷新”的简单逻辑，用StatefulWidget加FutureBuilder就能搞定。如果整个项目的路由和播放器状态已经用了Provider，那你可以顺手用Provider管理歌手列表的loading状态和数据缓存，但如果项目里还没引入，就不用为了这个页面单独引入Provider。我这边的经验是：小页面尽量少依赖重型状态管理，保持代码可读优先。

代码骨架大致是这样的：

class SingerListPage extends StatefulWidget { const SingerListPage({super.key}); @override State<SingerListPage> createState() => _SingerListPageState(); } class _SingerListPageState extends State<SingerListPage> { late Future<List<SingerModel>> _singersFuture; final ScrollController _scrollController = ScrollController(); @override void initState() { super.initState(); _singersFuture = _loadSingers(); } Future<List<SingerModel>> _loadSingers() { final repo = SingerRepositoryFactory.create(); return repo.fetchSingers(); } void _reload() { setState(() { _singersFuture = _loadSingers(); }); } @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar( title: const Text('歌手'), backgroundColor: Theme.of(context).colorScheme.surface, ), body: Column( children: [ _buildSearchBar(), Expanded( child: FutureBuilder<List<SingerModel>>( future: _singersFuture, builder: (context, snapshot) { if (snapshot.connectionState == ConnectionState.waiting) { return _buildLoadingSkeleton(); } if (snapshot.hasError) { return _buildErrorView(_reload); } final singers = snapshot.data ?? []; if (singers.isEmpty) { return _buildEmptyView(_reload); } return _buildSingerList(singers); }, ), ), ], ), ); } }

这种写法最直观，每个状态对应一个独立Builder方法，页面逻辑一眼就能看明白。后面你如果要把歌手列表做成带分类Tab的，也可以在这个基础上继续扩展。

3.2 歌手卡片布局的细节

歌手列表里最核心的视觉单元就是卡片。很多新手会直接用ListTile，我只能说能用但不专业。ListTile的高度、内边距都被系统预设了，很难做出现代音乐App那种“大图+丰富信息”的卡片效果。我更推荐自己组合Container、Row、Column来实现，虽然代码稍微多一点，但每一个像素都控制在自己手里。

我的卡片结构是这样的：左边56x56的圆形头像，右边两行文字，第一行是歌手名，字体稍大加粗；第二行是歌曲数和专辑数，字体偏小颜色偏灰。右侧放一个右箭头图标，提示可点击。

Widget _buildSingerCard(SingerModel singer) { return InkWell( onTap: () { Navigator.pushNamed(context, '/singer/detail', arguments: singer); }, borderRadius: BorderRadius.circular(12), child: Container( margin: const EdgeInsets.symmetric(horizontal: 12, vertical: 6), padding: const EdgeInsets.symmetric(horizontal: 12, vertical: 10), decoration: BoxDecoration( color: Theme.of(context).colorScheme.surfaceContainerHighest.withAlpha(80), borderRadius: BorderRadius.circular(12), ), child: Row( children: [ ClipOval( child: SizedBox( width: 56, height: 56, child: _buildAvatar(singer.avatarUrl), ), ), const SizedBox(width: 12), Expanded( child: Column( crossAxisAlignment: CrossAxisAlignment.start, mainAxisAlignment: MainAxisAlignment.center, children: [ Text( singer.name, maxLines: 1, overflow: TextOverflow.ellipsis, style: const TextStyle(fontSize: 16, fontWeight: FontWeight.w600), ), const SizedBox(height: 6), Text( '${singer.songCount}首歌曲 · ${singer.albumCount}张专辑', maxLines: 1, overflow: TextOverflow.ellipsis, style: TextStyle(fontSize: 13, color: Colors.grey.shade600), ), if (singer.category.isNotEmpty) Padding( padding: const EdgeInsets.only(top: 4), child: Text( singer.category, style: TextStyle(fontSize: 12, color: Colors.grey.shade500), ), ), ], ), ), Icon(Icons.chevron_right, size: 20, color: Colors.grey.shade400), ], ), ), ); }

头部圆形裁切这里要注意一个坑。ClipOval如果直接包一个Image.network，加载过程中图片还没下载完，会先显示一片空白区域，圆形里会闪过一大块白。我的改进方案是给头像包一层背景色或者先用本地占位图，让裁切后的区域始终有颜色填充，这样视觉上更平滑。

另一个细节是InkWell的圆角要跟Container的圆角保持一致，否则点击时水波纹会溢出到圆角外面，看着很粗糙。我在测试里曾因为漏传borderRadius参数，导致水波纹是矩形的，跟圆角卡片不匹配，那个视觉效果真的很劝退。

3.3 右侧字母索引：从A到Z的联动实现

音乐App的歌手列表几乎都有A-Z字母索引，它解决的问题是当歌手数量很多时，用户能快速定位到指定拼音首字母的位置。实现思路并不复杂，核心有两点：左侧列表要能够滚动到指定位置，右侧字母条要能感知当前滚动到了哪个字母。

右侧字母条我用了竖向排列的A到Z文本列表，外面包一个GestureDetector监听手指滑动。根据手指的Y坐标计算当前命中的字母，然后通过ScrollController把列表滚到对应位置。计算位置的逻辑是：先拿到当前手指在字母条内的相对高度，除以字母条总高度，再乘以26个字母，取整就能得到字母索引。

void _onIndexDrag(DragUpdateDetails details) { final renderBox = _indexKey.currentContext?.findRenderObject() as RenderBox?; if (renderBox == null) return; final position = details.localPosition.dy.clamp(0, renderBox.size.height); final index = (position / renderBox.size.height * (_letters.length - 1)).round(); final targetLetter = _letters[index]; final targetIndex = _getIndexForLetter(targetLetter); if (targetIndex >= 0) { _scrollController.animateTo( targetIndex * 72.0, // 前提是你知道每行卡片的固定高度 duration: const Duration(milliseconds: 200), curve: Curves.easeOut, ); } }

这里有一个前提条件：左侧列表必须使用固定高度卡片，才能用卡片高度x目标索引直接算出滚动偏移。如果卡片高度不固定，用这个算法滚不准。我在项目里先用72.0这个估算高度跑通，后来发现某些歌手名字过长换行后卡片高度变了，滚动位置就会偏差。最终我改成了按列表项真实高度累加计算的方式，或者干脆给每项固定高度并启用shrinkWrap。如果你不想被这个问题纠缠，最简单的做法是让卡片固定高度，比如身高固定为80，文字溢出部分用ellipsis处理。

联动还有个反向过程，就是列表滚动时高亮右侧对应的字母。这个用监听ScrollController的滚动事件也能做，但计算成本略高。简易实用方案里，我用的是列表项首字母去推断当前区段，在stop scrolling时更新一下高亮字母。这一期先不做实时高亮，等后面如果做通讯录式跳转再补上。

3.4 下拉刷新和搜索框的处理

歌手列表页的数据虽然不算高频变化，但用户可能有下拉刷新习惯。我在Flutter里用了RefreshIndicator，但它直接包ListView的时候会出现刷新指示器颜色和背景不匹配的问题。OpenHarmony上这个问题的表现尤其明显，指示器有时候会藏到状态栏后面去，解决办法是确保ListView始终在Scaffold的body区域内部，不要嵌在自定义滚动视图里。

搜索框我放在了列表页顶部，作用是对当前加载的歌手列表做本地过滤。也就是说，初始的数据还是从Repository拉全量歌手，用户输入关键词后再内存里用where过滤。这里有个细节：过滤的是歌手的name或category字段，匹配时要用toLowerCase()统一大小写，避免用户输入英文时匹配不上。

List<SingerModel> _filterSingers(List<SingerModel> singers, String keyword) { if (keyword.trim().isEmpty) return singers; final kw = keyword.toLowerCase(); return singers.where((s) { return s.name.toLowerCase().contains(kw) || s.category.toLowerCase().contains(kw); }).toList(); }

搜索状态如果用TextEditingController监听，要注意监听器的释放，不然在页面销毁的时候会报内存泄漏警告。我习惯在dispose里把controller释放掉，这是Flutter开发者很容易忽略的小问题。

4. 从歌手列表进入歌手详情：路由与参数传递

4.1 直接传对象还是传ID再查一遍

我从歌手列表点击卡片进入歌手详情页，最直接的想法是Navigator.push直接把SingerModel对象传过去。这个做法对简单的单页跳转是没问题的，因为Dart对象在内存里传递非常快，也不会牵扯到序列化问题。但一旦页面被系统回收或者跨进程使用，直接传对象就不太可靠了，比如从通知栏点击进入详情页时，你手里可能只有一个歌手ID，没有完整的歌手对象。

所以我的项目里做了两层设计：列表页跳详情页直接传对象，仅供正常操作路径使用；详情页内部再做一次兜底，如果发现对象缺失或者详情数据不是最新的，就根据id重新向Repository拉一次。这样两个入口的行为都能得到保证。

class SingerDetailPage extends StatefulWidget { final SingerModel? singer; final String? singerId; const SingerDetailPage({super.key, this.singer, this.singerId}); @override State<SingerDetailPage> createState() => _SingerDetailPageState(); }

详情页在initState里判断，如果widget.singer为空就用widget.singerId去加载。这个设计新增的代码量很少，但健壮性一下子提高了不少，后续你要做推送通知跳转或者是DeepLink都会舒服很多。

4.2 命名路由还是页面直接跳转

我在歌手列表这期里选择了命名路由，也就是在MaterialApp的routes里把/singer/detail注册好，这样后续从搜索页、播放页跳过去时都复用同一个路由配置。命名路由传参的方式是通过arguments字段，接收端在取参数时注意做类型校验，因为arguments是Object类型，直接强转可能会抛类型异常。

MaterialApp( routes: { '/singer/detail': (context) => const SingerDetailPage(), }, ); // 跳转时 Navigator.pushNamed(context, '/singer/detail', arguments: singer);

这里我踩过一个坑：如果SingerModel直接作为arguments传入，进入详情页后要立刻把arguments转成SingerModel，但这个SingerModel不一定是深拷贝来的，页面里如果改了它的某个字段，可能会影响上一层列表页的数据。歌手模型在项目里一般不会被单独修改，所以问题不大，但如果你的模型里有List或Map类型的可变字段，最好在详情页里拷贝一份副本再使用。

4.3 Hero动画的取舍

歌手列表跳到歌手详情页，很多音乐App会让圆形头像做一次缩放飞入的转场动画，这个效果在Flutter里用Hero组件实现非常顺滑。我在列表页的头像外层包了Hero，tag用的就是歌手id，详情页的头像也用同样的tag，这样Flutter会自动找匹配的Hero做动画。

但这里有个容易踩的坑：如果歌手列表页的头像是列表项里多个实例共用一个tag，或者列表页和详情页的tag不唯一，Flutter会抛“There are multiple heroes that share the same tag”异常。我一开始给列表页所有歌手头像都写了同一个tag字符串，直接崩溃，后来改成用歌手id拼接，比如singer_avatar_${singer.id}，才能确保唯一。

Hero( tag: 'singer_avatar_${singer.id}', child: ClipOval( child: SizedBox( width: 56, height: 56, child: _buildAvatar(singer.avatarUrl), ), ), )

同时要记得，详情页的头像Hero要保持同样的tag，否则动画不会触发。如果某个页面因为头像加载失败而用了占位图，它仍然会参与Hero动画，这一点不影响。

5. OpenHarmony适配与性能优化实录

5.1 Flutter for OpenHarmony的构建流程

我在项目里用的是社区维护的Flutter for OpenHarmony适配分支，整体流程大致是这样：先把适配分支的Flutter SDK下载下来，再在项目里通过flutter config指定SDK路径，之后用常规的flutter pub get和flutter build命令生成OpenHarmony产物。然后在DevEco Studio里打开工程中的ohos目录，把生成的Flutter模块作为依赖引入，最终打包成hap安装包。

一个容易踩的坑是SDK版本和OpenHarmony版本要匹配，否则编译期大概率会碰到“接口不存在”之类的报错。我的经验是先看当前分支的README里写着支持的最低OpenHarmony版本，再对照自己手头设备的系统版本，不要无脑用最新DevEco和最新设备系统，否则要被莫名其妙的问题折磨很久。

另外需要注意，OpenHarmony侧对资源文件的打包路径和Android是有区别的。Flutter的assets在使用时通过AssetManager加载，但是OpenHarmony分支的实现细节可能会让asset加载路径多一层前缀，我之前把图片资源放到assets/images后引用路径没问题，但放到assets/singers/images时，在OpenHarmony模拟器上会有偶发加载不出来的情况，最后把目录层级拍平后就稳定了。这个建议按你实际适配分支的表现去调整。

5.2 列表滚动性能优化

歌手列表几百个歌手是很常见的。直接在外层套一个ListView.builder的话，Flutter的懒加载机制会自动帮你按需构建，性能瓶颈更多出在item内部：头像图加载、阴影、圆角、透明度陷阱都会增加绘制成本。

我的优化手段有三个。第一，列表卡片用Container的decoration来实现阴影，不要用Material的elevation属性，后者在OpenHarmony分支上有时会产生额外的合成层；第二，头像裁剪优先用ClipOval，少用带有边框的圆形装饰，因为ClipOval直接走GPU裁剪路径，成本更低；第三，列表项里的文字颜色尽量用固定的Color值，避免用withOpacity去做半透明叠加，绘制流程里头半透明颜色会触发额外的混合计算。

实测下来最有效的还是给ListView.builder加上itemExtent固定高度。当itemExtent不为空时，Flutter滚动引擎可以直接跳过部分布局工作来估算滚动位置，列表的滑动流畅度会有非常直观的提升。我上一节提到按72.0计算跳转位置，最终也是跟itemExtent配合，两边参数一致，滚动体验才真正稳。

5.3 图片加载与缓存策略

歌手头像在网络图片加载失败时会显示一个裂图或者空白，这在OpenHarmony设备上特别显眼。我没直接用Image.network的原始能力，而是包了一个自己写的拓展方法，优先尝试本地缓存，缓存没有命中才走网络，同时强制设置loadingBuilder和errorBuilder。

Widget _buildAvatar(String url) { return Image.network( url, fit: BoxFit.cover, loadingBuilder: (context, child, loadingProgress) { if (loadingProgress == null) return child; return Container( color: Colors.grey.shade200, child: const Center(child: CircularProgressIndicator(strokeWidth: 2)), ); }, errorBuilder: (context, error, stackTrace) { return Container( color: Colors.grey.shade200, child: const Icon(Icons.person, color: Colors.grey), ); }, ); }

OpenHarmony分支里Image.network的底层实现如果没有支持内存缓存，频繁滑动列表会反复触发网络请求，我实测下来的确发现同一张头像在短时间内会被重复拉取很多次。解决办法是引入一个简单的内存缓存工具类，用Map或LRU策略存住已经加载过的ImageProvider，命中直接复用。这样列表回滚时不会看到图片闪一下重新加载的样子。

6. 常见问题排查与坑点速查

6.1 我实际踩过的典型问题记录

这一节我把做歌手列表过程中碰到的、并且网上资料比较少的问题整理成一个速查表，你在自己的项目里如果遇到类似现象，可以按图索骥。

问题列表与排查思路

排查这些问题的顺序，我的经验是先看日志有没有异常，再看是不是渲染层的问题，最后才怀疑数据源。因为Flutter的ErrorWidget有时候会被FutureBuilder吞掉一部分，你得在调试模式里跑一遍，把所有异常打印出来，很多晦涩问题立刻就有线索了。

6.2 一个让我花了一晚上排查的诡异问题

歌手列表在OpenHarmony真机上偶发点击卡片没反应，但在模拟器上却一切正常。当时我怀疑是InkWell的问题、路由的问题、手势冲突的问题，排查了一圈都没结果。后来打开日志才发现，是某次网络请求失败了，页面其实已经切换到了错误状态，但错误视图的背景色和列表背景色一样，用户误以为页面还在列表，所以怎么点都没用。

这个经验让我养成了一个习惯：每个页面状态之间切换，背景色或UI结构要尽量做出明显区分，尤其是错误态和空白态，不能跟正常态太像。像这种“偶发不可交互”的问题，先确认当前屏幕到底渲染的是哪个状态，再谈后续排查。日志里打一行当前state名称，能帮你省下大量怀疑人生的时间。

6.3 实测下来值得保留的小技巧

关于OpenHarmony上调试，我个人的建议是不要只依赖Hot Reload。我在开发歌手列表时经常用Hot Reload跑UI，但OpenHarmony分支对Hot Reload的支持偶尔不稳定，会出现界面更新了但状态没重置的情况。遇到这种问题，先把应用彻底停止再重新运行，不要怀疑自己的代码，大概率是Reload链路的问题。

列表页性能测试建议在低端真机上跑，OpenHarmony模拟器性能虚高，很多滚动卡顿在模拟器上是测不出来的。我最后一遍优化就是在一台配置偏低的设备上反复滑动才发现了itemExtent和阴影合成的优化收益。数据量也别只用二三十条试，建议直接在代码里生成几百条模拟数据，把列表撑到远超一个屏幕的高度，这样才能暴露真实性能问题。

7. 最后再说一点个人体会

歌手列表这个模块做完之后，我最大的感触是：越是看起来简单的页面，越要把数据模型和路由协议先想清楚。你当然可以五分钟堆一个LocalListTile出来，但后面搜索页要做歌手入口、播放页要做点击跳转、详情页要做缓存回刷，到时候这种草率实现会在每一个环节都给你找麻烦。我这几期反复在强调“先定模型再写界面”，就是因为吃过太多返工的亏。实际开发中先把SingerModel、Repository、路由规则这三件套定下来，然后任何页面需要歌手数据，都走同一套逻辑，整个项目的复杂度反而会降低。这一期内容写到这里，代码量不算大，但里面的坑和数据设计思路，应该能帮你在做类似模块时少走不少弯路。