最近在折腾 Flutter 做跨平台应用，其中一个重点就是鸿蒙系统的适配。项目里用到最多的组合就是 Card 加列表，基本上所有信息流页面都离不开这套结构。说实话，一开始我觉得 Card 不过是一个带圆角阴影的容器，直到真正把列表做复杂之后才发现，里面的门道远比想象中多。这篇就把我这段时间在 Flutter 跨平台鸿蒙开发中，Card 在列表里的应用经验整理出来，从环境搭建到基础用法，从性能优化到疑难排查，尽量把能踩的坑都提前给你标出来。

1. 为什么把 Card 和列表绑在一起

1.1 信息流场景里 Card 的价值

做移动端应用的都知道，信息流页面几乎都是“列表 + 卡片”的天下。新闻资讯、商品陈列、社交动态、任务清单，随便打开一个主流应用，界面上一眼望过去基本就是一张张卡片排成一个列表。为什么这种模式如此普及，因为 Card 本质上是一个内容容器，它能把标题、描述、图片、按钮、标签这些不同形态的信息收纳进一个独立的视觉单元里，让用户在快速浏览时能自然地把一块内容当作一个整体来理解。

在 Flutter 里，Card 是基于 Material Design 的组件，自带圆角、阴影和边框效果，不需要你额外去画背景或者调整控件层级。也就是说，你只需要把内容丢进 Card，它就能在视觉上和其他区域区分开。配合列表的滚动特性，卡片可以承载独立的数据项，每张卡片对应一条记录，用户的心智模型是“一卡一物”，这比单纯用分隔线切分长列表要清晰得多。

从开发效率角度看，Card 的封装性也特别好。同一个列表页里，卡片内部的结构可能是完全一样的，只是数据不同，这就非常适合抽成独立的 widget 复用。我在项目里就是把“卡片”拆成了一个单独组件，然后通过构造参数传入不同的数据模型，列表只需要负责遍历数据、创建卡片实例，业务逻辑清晰，后期维护也很简单。

1.2 为什么跨平台方案选了 Flutter

选择 Flutter 做这次的鸿蒙适配，其实是经过一轮对比的。团队里同时有 React Native 和 Flutter 两种技术栈，但在这个项目上我坚持用 Flutter。原因主要有三点。

第一，UI 渲染一致性高。Flutter 是自绘引擎，不依赖系统原生控件，它通过 Skia 图形引擎直接绘制每一帧画面。这意味着同一套代码在不同平台上的视觉效果非常接近，尤其 Card 的圆角、阴影、波纹这些细节，在鸿蒙、安卓、iOS 上都能保持一致的观感，不会出现“安卓上好好的，换个系统就变形”的尴尬。

第二，性能表现稳定。Flutter 的渲染管线是独立的，列表滚动时配合 RepaintBoundary 等机制，可以避免不必要的重绘。在鸿蒙设备上实测，用 ListView.builder 渲染几百条 Card 列表，滚动帧率也能稳定在 90 帧左右（鸿蒙的高刷新率设备），这个表现我已经很满意了。

第三，生态和工具链成熟。Flutter 的包管理、状态管理、调试工具都很完善，哪怕要针对鸿蒙做定制化适配，社区也已经积累了不少方案，不至于所有问题都从零啃。

当然，跨平台不是银弹，Flutter 在鸿蒙上也有一些需要额外处理的差异点，比如某些系统能力的调用、文件路径的获取方式，这些我会在后面的常见问题部分单独展开。

2. 开发环境与工程配置

2.1 Flutter 鸿蒙环境的搭建要点

如果你之前在安卓或者 iOS 上跑过 Flutter，那么搭鸿蒙环境的整体思路是一样的，但有几个坑需要提前留意。

首先是版本匹配。Flutter 官方对鸿蒙的支持是从 3.19 版本开始逐步完善的，到 3.22 之后已经可以比较顺畅地创建鸿蒙工程了。我这里使用的是 Flutter 3.22+ 的版本，配合 DevEco Studio 5.x 版本。版本之间要求严格对应，如果你手里的 Flutter 版本太新或者太老，都可能在编译时出现 SDK 不兼容的报错。

其次是鸿蒙 SDK 的路径配置。Flutter 在编译鸿蒙工程时需要找到 HarmonyOS 的 SDK 路径。这个路径一般在你的用户目录下，例如Sdk目录里会包含openharmony和harmonyos两个子目录。安装完成后，需要把 SDK 路径配置到环境变量里。我电脑上配置的是HOS_SDK_HOME，指向我实际安装的 SDK 根目录。

然后是 DevEco Studio 的配套工具链。Flutter 构建鸿蒙应用时，最终还是要把 Dart 代码打包成原生鸿蒙工程可以加载的形态，这个环节依赖 DevEco Studio 的编译工具。所以你需要提前安装 DevEco Studio，并且在它的 SDK Manager 里把Native、JS等必要的组件都装好，否则编译到一半会报缺这个缺那个。

还有一个容易忽略的点是 Java 环境。Flutter 构建鸿蒙应用的过程中会用到 Gradle，而 Gradle 依赖 JDK。建议安装 JDK 17，并且确认java -version能正常输出。我之前因为本机默认 JDK 是 8，折腾了半个多小时，最后才发现是环境变量顺序问题。

2.2 创建支持鸿蒙的 Flutter 工程

环境配好之后，创建工程有两种方式。

第一种，直接在 Flutter 命令行中执行：

flutter create --platforms=ohos my_cross_app

这个命令会生成一个包含ohos平台目录的 Flutter 工程，ohos目录下就是鸿蒙原生工程的骨架。

第二种，创建完普通 Flutter 工程后，再通过 DevEco Studio 打开，手动添加鸿蒙平台的模块，这种方式适合已有 Flutter 项目需要临时增加鸿蒙支持的场景。

工程创建好之后，进入项目根目录，pubspec.yaml文件里基本不需要特殊配置，Flutter SDK 会自动处理鸿蒙平台的依赖。不过有一点需要注意：如果项目里用到了第三方插件，一定要确认这个插件是否支持鸿蒙平台。多数常见的 Flutter 插件（如dio、provider、cached_network_image）都是纯 Dart 实现或者有对应的鸿蒙适配版本，但个别依赖原生安卓代码的插件在鸿蒙上就会编译失败。我遇到过一个本地存储插件，就是因为底层用到了安卓私有 API，导致鸿蒙构建直接报错。这种情况的处理方案是：要么找功能等价的支持鸿蒙的插件，要么自己用 Platform Channel 写一个轻量封装。

工程结构上，ohos目录里也有类似安卓gradle的构建配置。通常不需要手动修改，Flutter 工具链会生成一个entry模块作为应用入口。首次编译时间会比较长，因为需要把 Flutter engine 的鸿蒙版本相关内容拉取下来，耐心等就行。

3. 列表的基础框架

3.1 ListView 的基本用法

列表的载体我优先选 ListView，这是 Flutter 里最基础的滚动列表组件。它的用法非常直观：

ListView( children: [ Card(child: Text('第一条')), Card(child: Text('第二条')), // ... ], )

直接把 Card 作为 ListView 的 children，是最简单也最容易理解的写法。这种写法适合列表项数量固定、并且数量不会太多的场景，比如一个不超过 20 条数据的设置页、个人主页之类的。

但这里有一个非常关键的认知：ListView 的children构造会把所有子项一次性全部构建出来。如果你要展示的数据有成百上千条，这种写法会造成两个问题。第一，内存占用高，所有卡片 widget 都常驻在内存里。第二，首次构建慢，页面加载时要一次性创建所有子项，用户会明显感觉到卡顿。

所以我在项目里有一条铁律：凡是数据量不确定的列表，一律不用ListView(children: [...])这种写法，而是用 ListView.builder。

3.2 用 ListView.builder 打造长列表

ListView.builder 是懒加载模式的列表，它只在用户滚动到某个位置附近时才去构建对应的子项，离开视口后相关资源会被回收。这就像你读一本很厚的书，不需要把整本书的内容都背下来，只需要把当前页和前后几页的内容准备好就行。

ListView.builder( itemCount: cardList.length, itemBuilder: (context, index) { return AppCard(data: cardList[index]); }, )

itemCount告诉列表总共有多少项，itemBuilder则负责返回每一项的 widget。对于数据量大的场景，这种写法无论列表里有一千条还是一万条，内存占用都相对平稳。

不过 itemBuilder 也有一个容易被忽略的特质：它并不是只在“可见”时才调用。Flutter 的列表缓存机制会额外构建一些预加载区域（cacheExtent）内的项，默认是在视口前后各缓存 250 像素的内容。这样做是为了滚动体验更顺滑，避免快速滑动时新出现的项还没准备好。但如果你构建一个 Card 的代价很高（比如里面有复杂的图片处理），可能会在快速滑动时出现短时间的空白或者掉帧。后面我会在性能优化部分详细说怎么处理这类问题。

说完 ListView 的基础，就要把焦点放到真正的核心——Card 上面来。

4. Card 组件的样式与布局细节

4.1 Card 的核心属性

Flutter 的 Card 组件继承自 Material widget，它在内部已经封装好了默认的圆角、阴影和边距。先看一个最常用的配置示例：

Card( margin: EdgeInsets.symmetric(horizontal: 16, vertical: 6), elevation: 2, shadowColor: Colors.black.withOpacity(0.15), shape: RoundedRectangleBorder( borderRadius: BorderRadius.circular(12), side: BorderSide(color: Colors.grey.shade200, width: 0.5), ), clipBehavior: Clip.antiAlias, child: ..., )

这里面的几个属性，每一个都有讲究。

margin是卡片之间的间距。列表里的卡片如果贴在一起，视觉上会显得非常拥挤，所以通常会给上下左右留出合适的间距。我习惯用水平 16、垂直 6 的组合，这个数值在大多数手机屏幕上都能获得舒适的呼吸感。

elevation是阴影高度。Material Design 里阴影代表元素离纸面的“高度”，值越大阴影越重。但在列表场景我不建议用太大的 elevation，因为每张卡片都带厚重阴影的话，整个页面会显得非常脏，而且阴影绘制也会增加 GPU 负担。日常列表卡片用1到3就够了。

shape决定卡片的边框和圆角。默认 Card 只有圆角没有边框，但在某些内容较多、背景复杂的页面上，给卡片加一圈淡淡的描边可以增强边界感。圆角建议控制在8到16之间，太小的圆角缺乏卡片感，太大的圆角又会让内部内容的排版空间变紧张。

clipBehavior这个属性特别容易被忽略。它控制 Card 的圆角是否能裁切内部的子内容。默认情况下 Card 的圆角并不会裁切 child，也就是说如果 child 是一个圆角矩形图片，你可能会在卡片四角看到图片的直角戳出圆角范围。设置为Clip.antiAlias后，子内容会被圆角边界裁掉，视觉上就干净了。这个属性对列表里的图片卡片尤为重要。

4.2 列表卡片的内容分层

一张 Card 在列表里承载的往往是结构化信息，而不是一段孤零零的文字。我通常会把它分成几个清晰的区域：顶部信息区、中央内容区、底部操作区。结构上的实现方式就很自然了，用 Column 或者 Padding 把内容组织起来。

下面是我项目里一个比较典型的卡片结构：

Card( margin: EdgeInsets.symmetric(horizontal: 16, vertical: 6), clipBehavior: Clip.antiAlias, elevation: 2, child: Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ // 顶部区域：标题 + 状态标识 Padding( padding: EdgeInsets.fromLTRB(16, 12, 16, 4), child: Row( mainAxisAlignment: MainAxisAlignment.spaceBetween, children: [ Expanded(child: Text('任务名称', style: TextStyle(fontWeight: FontWeight.bold, fontSize: 16))), Text('已完成', style: TextStyle(color: Colors.green, fontSize: 12)), ], ), ), // 内容区域：描述信息 Padding( padding: EdgeInsets.fromLTRB(16, 4, 16, 8), child: Text('这里是任务的详细说明文本', style: TextStyle(color: Colors.grey.shade700, fontSize: 14)), ), // 底部区域：操作按钮或附加信息 Padding( padding: EdgeInsets.fromLTRB(16, 8, 16, 12), child: Row( children: [ Icon(Icons.access_time, size: 14, color: Colors.grey), SizedBox(width: 4), Text('2025-06-01', style: TextStyle(color: Colors.grey, fontSize: 12)), ], ), ), ], ), )

为什么要在 Card 内部用 Column 而不是直接放多个 child？因为 Card 本身不负责内容排版，它的职责是提供视觉容器，内容区域需要你自己组织。Column 加上合适的 Padding，可以在视觉和逻辑上把信息块区分开，同时保证触摸区域足够大、文本间距合理。

还有一个细节：如果卡片内部的文本行数不确定，务必对文字样式设置maxLines和overflow属性，例如：

Text( description, maxLines: 2, overflow: TextOverflow.ellipsis, )

这是列表卡片的常规操作。如果描述文本过长而不限制行数，卡片高度就会忽高忽低，列表滚动时会出现明显的跳动感，体验非常糟糕。

4.3 圆角、阴影的跨端差异

虽然 Flutter 是自绘引擎，理论上跨端一致性很好，但在鸿蒙设备上实测之后，我发现阴影和圆角的呈现还是有一些细微差异。

第一，阴影的渲染效果。鸿蒙设备上 Card 的 elevation 阴影默认是绘制在卡片“下方”的一层半透明投影，视觉风格比安卓原生要稍微硬一点。如果你发现阴影在个别机型上显得特别重，可以不用 elevation，而是自定义阴影颜色和 blur 强度。但需要注意，不要让阴影过度影响列表的滚动性能，尤其是低端设备上，大面积阴影会导致 GPU 负载偏高。

第二，圆角半径的视觉大小。同一套BorderRadius.circular(12)，在不同分辨率和屏幕密度的鸿蒙设备上，视觉圆角会略有差异，因为 Flutter 按逻辑像素计算，而高密度屏幕会把物理像素匹配得更加“细密”。这个不会造成功能问题，但如果你的设计稿对圆角有严格像素要求，建议在真机上多检查几台不同分辨率的设备。

第三，抗锯齿的表现。鸿蒙平台不同机型使用的 GPU 驱动不同，个别设备在圆角边缘会出现轻微的锯齿感。解决办法是开启Clip.antiAlias，让 Flutter 对圆角边界做抗锯齿处理。虽然会有一点性能开销，但考虑到视觉收益，这笔开销是值得的。

5. 列表与 Card 的性能优化

5.1 图片加载与内存管理

列表页的卡片里如果有图片，性能问题就会立刻放大。一个常见的错误写法是直接用Image.network(url)，每次 itemBuilder 被调用时都重新发起网络请求，图片解码也完全不做缓存，这样的列表在快速滑动时会不断闪现加载占位图，内存也会被大量无效图片数据撑爆。

我的建议是统一使用cached_network_image插件做图片加载。它基于 Flutter 的图片缓存体系，自动处理了磁盘缓存和内存缓存。第一次加载时显示占位图，图片下载完成后缓存起来，再次滚动回来时几乎瞬时显示。

另一个和图片相关的坑是图片尺寸。如果服务端返回的图片是 2000 像素宽的高清大图，而卡片里显示区域只有 200 像素宽，直接加载大图会造成巨大的解码开销。最稳妥的做法是让服务端支持按需裁剪，或者在使用cached_network_image时通过memCacheWidth和memCacheHeight参数指定缓存解码尺寸。这样 Flutter 在解码时就会生成缩略图，而不是把原图完整解码后硬塞进内存里。

CachedNetworkImage( imageUrl: item.coverUrl, memCacheWidth: 400, memCacheHeight: 300, fit: BoxFit.cover, placeholder: (context, url) => Container(color: Colors.grey.shade200), )

5.2 避免无谓重构：key 与 const

列表在滚动、刷新、删除时的性能，很大程度上取决于 Flutter 是否高效地复用了已有的 widget。这里有两个关键字必须用好：key和const。

先说const。如果 Card 的 child 是一段不会变的静态文本，或者是一个图标，尽量在 widget 树里加上const。例如：

const SizedBox(height: 8), Icon(Icons.access_time, size: 14, color: Colors.grey),

这些const声明可以让 Flutter 编译器在构建时复用同一个实例，减少无谓的对象创建。列表项数量一多，这个优化带来的收益会被放大得很明显。

再说key。当列表数据发生变化，比如插入了新项、删除了旧项，Flutter 需要判断哪些 widget 可以复用，哪些需要重建。如果每张 Card 都有专属的key，Flutter 就能快速匹配新旧状态，复用对应的 Element 和 State。

AppCard( key: ValueKey('card_${item.id}'), data: item, )

这里一定要用数据中稳定的唯一标识，比如数据库里的自增 id。千万不要用列表索引作为 key，因为插入或删除数据后，索引会整体移位，导致 Flutter 整张列表的匹配逻辑全部错乱，反而带来严重的重建开销和状态错乱。

5.3 滚动性能与渲染优化

列表滚动掉帧是很多开发者遇到的第一道坎。除了图片和重建问题，还有一个隐藏的元凶：没有隔离重绘范围。

你在列表里如果放了一张会定时的动画图，或者一个实时更新的进度条，那么 Flutter 在没有优化的情况下可能会让整张卡片甚至整个列表一起重绘。解决方案是在需要独立刷新的区域外包一层RepaintBoundary。

RepaintBoundary( child: AppCard( data: item, progress: item.progress, ), )

RepaintBoundary 会把子 widget 的绘制结果缓存成独立的层。这样当 progress 变化导致卡片内部某个局部刷新时，Flutter 只需要重绘这一层，而不需要触发列表整体重绘。对于包含多张卡片的长列表，这个优化对滚动流畅度的提升非常明显。

还有一个我吃过亏的地方：避免在itemBuilder内部做耗时操作。比如字符串处理、日期格式化、JSON 解析，这些都应该在数据层提前完成，然后直接传给卡片渲染。itemBuilder只做一件事——根据传入的数据构建 widget，这样它才能保持轻量和高频调用下依然稳定。

6. 交互与状态管理

6.1 卡片的点击、选择与滑动操作

列表里的卡片几乎都不是纯展示的，用户会点击、会选中、会滑动删除。这些交互在 Flutter 里处理不当会出现各种奇怪的问题。

最常见的点击实现是给 Card 外层包一个InkWell，利用 Material 的水波纹反馈来提升点击体验：

Card( child: InkWell( onTap: () => _handleTap(item), borderRadius: BorderRadius.circular(12), child: ..., ), )

这里有两个细节。第一，必须给 InkWell 设置和 Card 一样的borderRadius，否则水波纹的形状会和卡片圆角不一致，看起来非常别扭。第二，如果 Card 设置了clipBehavior: Clip.antiAlias，水波纹会被圆角裁切，视觉效果更自然一些。

如果要添加滑动删除功能，我推荐用Dismissible包装卡片：

Dismissible( key: ValueKey(item.id), direction: DismissDirection.endToStart, onDismissed: (direction) { _removeItem(item.id); }, background: Container( alignment: Alignment.centerRight, color: Colors.redAccent, child: Padding( padding: EdgeInsets.only(right: 24), child: Icon(Icons.delete, color: Colors.white), ), ), child: AppCard(data: item), )

注意，Dismissible本身也要求 key 是稳定且唯一的。滑动删除后，onDismissed回调里必须同步更新数据源，否则列表底部的itemCount和实际数据数量不一致，会直接触发越界异常，这也是一个很容易踩的运行时崩溃点。

6.2 下拉刷新与加载更多

卡片列表不是静态的，几乎都需要支持下拉刷新和滚动加载更多。下拉刷新可以用 Flutter 内置的RefreshIndicator组件：

RefreshIndicator( onRefresh: _loadLatestData, child: ListView.builder(...), )

加载更多通常是监听滚动位置，接近列表底部时触发下一页请求。实现时有个常见的性能隐患：如果你在NotificationListener<ScrollNotification>的回调里判断metrics.pixels > metrics.maxScrollExtent - 200就去请求加载更多，那一次滚动过程中这个回调会被触发很多次，如果不做防抖，就会造成重复请求。

我的做法是为加载更多的触发加上锁标识：

bool _isLoadingMore = false; bool _shouldLoadMore(ScrollNotification notification) { if (_isLoadingMore) return false; if (notification.metrics.pixels <= notification.metrics.maxScrollExtent - 200) return false; _isLoadingMore = true; return true; }

在请求完成后将_isLoadingMore置回 false，这样能保证同一时间只存在一个正在进行的加载更多请求。这个小细节救了我很多次，不然用户快速划到底部时，后台瞬间堆出五六个重复请求，接口和数据库都受不了。

6.3 状态管理方案的选择

列表页的数据刷新，用 Flutter 自带setState就能跑通，但当列表页和详情页、全局状态之间有联动时，就要考虑状态管理了。

我这次项目用的是provider，因为它的概念足够简单，对像 Card 列表这样的场景完全够用。状态管理的核心思路是把“数据”和“UI”分离：列表页只关注页面渲染，所有数据操作都通过状态管理类来完成。

比如我定义一个ItemListModel继承ChangeNotifier：

class ItemListModel extends ChangeNotifier { List<Item> _items = []; bool _loading = false; List<Item> get items => _items; Future<void> fetchData() async { _loading = true; notifyListeners(); _items = await api.fetchItems(); _loading = false; notifyListeners(); } }

列表页通过Consumer来监听数据变化：

final model = context.watch<ItemListModel>(); ListView.builder( itemCount: model.items.length, itemBuilder: (context, index) => AppCard(data: model.items[index]), )

使用provider的好处是，Card 内部如果也要监听状态，比如根据收藏状态切换图标，直接使用context.watch就能精准刷新，而不会牵连整个列表页。这在列表项较多时，能明显降低刷新范围。

7. 常见问题与排查技巧

7.1 鸿蒙适配中的典型问题

跨平台开发最让人头疼的就是平台差异，鸿蒙也不例外。我在适配过程中遇到三个高频问题，这里单独列一下。

第一个，文件路径差异。Flutter 里获取临时目录通常用Directory.systemTemp，但在鸿蒙平台上，这个路径的实际位置和安卓不太一样，如果你直接把路径写死传给原生模块，可能会找不到文件。解决思路是不要硬编码路径，统一用path_provider插件来获取平台对应的目录。鸿蒙的适配版本叫path_provider_ohos，装上之后用法和原版几乎一致。

第二个，通知权限与后台行为。鸿蒙对后台任务的管控比安卓更严格，如果你的列表页涉及后台刷新或者推送，一定要处理权限申请的逻辑。Flutter 侧无法直接申请所有原生权限，需要借助鸿蒙原生侧的能力，或者使用支持鸿蒙的权限插件。

第三个，屏幕安全区。鸿蒙的全面屏手势区域、状态栏高度和安卓略有区别。如果你的列表卡片用到了SafeArea，要注意鸿蒙设备底部手势条的避让逻辑。我的做法是给列表外层的Padding动态适配安全区，避免卡片内容被手势条遮挡。

7.2 列表卡顿、滑动掉帧的处理

如果列表滚动时出现掉帧，优先排查顺序建议是：图片加载是否过度 → 是否有不必要的重绘 → ItemBuilder 里是否有耗时操作 → 列表项是否过重。

一个具体案例：我曾经把一个 3D 动画的 widget 放在某几张卡片里，结果列表滑动时明显卡顿。后来用RepaintBoundary把动画 widget 单独隔离，卡顿立刻改善。所以我每次遇到掉帧，第一反应就是检查“重绘边界”是否合理。

还有一个容易被忽视的点：shrinkWrap属性。如果你把 ListView 嵌套在 Column 或者另一个滚动容器里，并且设置了shrinkWrap: true，这会强制列表计算全部子项的高度，直接破坏懒加载机制。列表项少还好，一旦数据量大，页面会瞬间卡死。列表嵌套的页面我建议直接用CustomScrollView+SliverList来替代。

7.3 点击事件与手势冲突

卡片上如果有按钮，又有整个卡片的点击事件，很容易出现事件冲突。比如一个卡片整体可点击跳转详情，同时卡片底部有一个收藏按钮，如果收藏按钮没有正确处理，点击收藏时可能会同时触发卡片的跳转。

解决思路是：子按钮用GestureDetector或者InkWell包裹时，不要让它的事件继续冒泡。Flutter 的事件机制中，InkWell的 onTap 会竞争手势识别，但如果父子都有 tap 识别器，子级通常赢得比赛。不过我仍然建议在收藏按钮上使用IconButton，它能天然拦截点击事件，再配合一个onPressed回调消费掉事件，就不会触发父级的 onTap。

如果遇到更复杂的嵌套滑动冲突，可以通过GestureDetector的behavior参数或者RawGestureDetector来精细控制手势竞争。这个在卡片内部放横向滚动的标签栏时尤其重要。

8. 写在最后的实操心得

如果要把这套经验浓缩成几句话，我首先想说的是：Card 在列表里不只是 UI 组件，它承载的是整个信息的组织逻辑和交互入口。花时间把卡片内部的结构定义清楚，把数据流规划好，比在样式上抠细节重要得多。

我的习惯是每做一个新列表页，先画一个卡片的“信息结构图”，确定哪些字段该放哪些区域，哪些内容会变化、哪些不会，然后才动手写代码。这样做的好处是把问题在动手前就暴露出来，而不是等写完代码再返工。

另外，不要迷信某一个组件的默认表现。Card 的默认样式在简单场景下省事，但一旦进入真实业务，几乎都需要自定义 shape、调整 margin、处理 clipBehavior。把这些属性理解透了，才能真正发挥它的作用。

最后想提醒的是，跨平台开发一定要在自己目标平台上多验证，不能只在模拟器上跑通就算完。鸿蒙设备的屏幕比例、系统版本、后台策略都和其他平台有差异，很多问题只会在真机上出现。如果你正在做类似的项目，一定记得预留足够的真机调试时间。