企业官网建设流程全解析

从去年把主力 Flutter 应用往鸿蒙生态迁移开始，最让我挠头的竟然不是架构改造，而是首页那一套 GridView 应用宫格。在 Android 上看着挺顺眼的卡片网格，一到鸿蒙上圆角发毛、阴影发虚、文字底部被截掉一小截，还时不时给我冒个 overflow 黄条。后来我把 GridView 的自定义样式从头捋了一遍，从 item 布局、间距计算、分隔线到阴影圆角系统性地重新封装，顺手把 Flutter 跨平台到鸿蒙后的渲染差异、事件通道、滚动性能这些坑也一起填平了。这篇就把这套"Flutter 框架跨平台鸿蒙开发——GridView 自定义样式"的完整设计思路、代码实现和避坑记录整理出来，给正在做鸿蒙适配或者想系统掌握网格页重构的朋友做个参考。

无论你是刚接触 Flutter 的新手，还是已经写了很久跨平台业务的老手，只要你的页面里出现过宫格、商品卡、瀑布流、标签墙这些网格形态的东西，这篇里的方案和踩坑经验应该都能用得上。下面我从方案选型开始，一步步展开。

1. 为什么 Flutter 能跨到鸿蒙，GridView 又凭什么单独拿出来说

1.1 跨平台落地的底层逻辑

先聊个大的：Flutter 凭什么能跑到鸿蒙上。Flutter 落地到任何一个新平台，本质只需要两件事——引擎层能跑，插件通道能通。引擎层负责 Dart 代码的执行和自绘渲染，也就是说 Flutter 页面的渲染不依赖系统的原生控件，而是 Flutter 自己用 Skia/Impeller 把每一帧画到屏幕上。官方和社区合力把 Flutter Engine 对 OpenHarmony 的适配推进到可落地状态之后，绝大多数 Dart 代码几乎可以原封不动地复用，这就比从一套原生 UI 框架迁到另一套原生 UI 框架省力太多。ArkUI 页面和 Flutter 页面的关系，更像是在一个系统里跑了一个独立的图形运行时，而不是把原生控件包了一层 UI。

但这也会带来一个隐藏问题：正因为渲染是自绘的，字体、圆角、阴影、文本换行等一系列排版细节，在不同平台的引擎配置不一样，最终表现就可能走样。GridView 是列表类组件里最容易暴露这种差异的，因为它同时牵扯间距、比例、滚动、复用四个层面的联动，任何一个参数对不上，视觉就会失真。我在鸿蒙上遇到最典型的现象，就是 childAspectRatio 这个比例参数在 Android 上算得好好的卡片比例，到鸿蒙上因为默认字体行高不同导致内部溢出，底部文字被裁掉。这类"看起来一样的代码，跑起来不一样"的坑，只能在实际适配里慢慢摸。

1.2 网格页在鸿蒙应用里到底有多能打

在迁移之前，我统计过团队应用里 GridView 的使用场景：首页宫格入口、商品瀑布、文件夹列表、信息流卡片、搜索历史标签，一共七个页面直接用了 GridView。说实话，这些页面如果单独用鸿蒙 ArkUI 重写，每个至少两三天排期，七个页面就是半个月到一个月的开发量。而基于 Flutter 引擎的复用，我只改了一套公共组件库里的网格样式封装，再把少数几个特例页面单独处理，大多数页面的数据和业务逻辑一行都没动，这就是跨平台在工程维度上最实在的红利。

GridView 之所以值得单独写一套自定义样式，是因为这些网格页虽然都叫 GridView，但细节差别很大：有的是两列卡片、有的是三列图标宫格、有的是标签流的自适应排列、有的需要表格型分隔线。如果每个页面都自己写一套 item 样式，代码就成了散装拼盘，改个主题色恨不得全项目翻一遍。把这些统一抽象成一套可配置样式的网格组件，才是真正把跨平台红利吃到嘴里的做法。

2. 网格方案选型与数据模型设计：动手前先算清三笔账

2.1 先选对 gridDelegate，否则后面都是白干

GridView 的排布逻辑完全由一个 gridDelegate 决定，常见两个：SliverGridDelegateWithFixedCrossAxisCount 和 SliverGridDelegateWithMaxCrossAxisExtent。前者是"固定列数"——不管屏幕多宽，我都给你分成 3 列或 2 列；后者是"固定最大宽度"——每项宽度不超过某个值，屏幕宽的自动多分几列，屏幕窄的少分几列。

做鸿蒙适配的时候，我强烈建议先想清楚你的页面到底要哪种。拿首页宫格来说，产品的要求是"不管什么终端，一屏必须显示 8 个入口，两行四列"，这种就必须用 FixedCrossAxisCount，列数写死 4。而内容瀑布流这类场景，理想状态是每个卡片宽度不要太大，尤其是平板上要自动多列，这种用 MaxCrossAxisExtent 更合适。比如 maxCrossAxisExtent 给 180，手机屏宽 360 时一屏分两列，平板屏宽 720 时就四列，完全不需要手写 MediaQuery 去做分辨率适配。两者差异的实质是：一个以列数为锚点，一个以宽度为锚点。锚点选错，后面所有样式都是在沙子上盖楼。

选好 delegate 后还有三个参数要同步定下来：mainAxisSpacing 是主轴方向的间距，在垂直滚动的网格里就是上下两个卡片之间的缝隙；crossAxisSpacing 是交叉轴方向的间距，在垂直滚动里就是左右列之间的缝隙；childAspectRatio 是每个 cell 的宽高比。这三个参数我建议直接从设计稿量出来，而不是靠肉眼估。间距差 2dp 在单张卡片上几乎看不出来，但一整屏滚动起来就非常明显，尤其在鸿蒙的深色模式下，间距不均的观感会被放大。

有人会问：既然有间距参数，我直接在 item 里用 Padding 包一层，效果不一样吗？这种方案的坏处在于，item 的响应区域和视觉区域会脱节，点击热区、阴影边界、视觉间距都会乱套。无论什么场景，我都建议间距优先通过 gridDelegate 控制，item 内部的 Padding 只负责处理内容内边距，比如文字距离卡片边缘的留白。

2.2 数据模型里该放哪些字段，决定样式能做成多灵活

我一开始偷懒，item 字段就放 title、imageUrl、onTap 三个，后面接需求时发现角标、置灰、锁定状态全都得往上堆，结果在 itemBuilder 里写了一大堆 if else。这里有个教训：网格 item 的数据模型一定要把业务字段和样式状态字段分开设计。

以一个标准的卡片模型为例，我会这样定义：

class GridItemModel { final String id; // 唯一标识，用于列表复用和埋点 final String title; // 主标题 final String subtitle; // 副标题，可为空 final String imageUrl; // 图片地址 final String? tagText; // 角标文案，如"新品""热门" final int badgeCount; // 数字角标，如未读消息数 final bool isLocked; // 锁定置灰状态 final bool isHighlight; // 是否高亮显示 final VoidCallback? onTap; // 点击回调 const GridItemModel({ required this.id, required this.title, required this.imageUrl, this.subtitle = '', this.tagText, this.badgeCount = 0, this.isLocked = false, this.isHighlight = false, this.onTap, }); }

前端拿到数据后，在 itemBuilder 里直接按字段渲染，不要在 widget 里写一堆逻辑去猜样式。比如 isLocked 为 true 时统一给卡片叠一层灰蒙层，badgeCount 大于 0 时在右上角渲染红色数字角标。这套模型后来在鸿蒙适配中几乎没怎么改，因为页面展示的复杂性已经被字段穷举掉了，剩下的事情都是纯粹的面板组装。

2.3 尺寸计算闭环：从设计稿到 childAspectRatio 的一步步推算

这是 GridView 自定义样式里最容易翻车的一环。我见过不少人凭感觉填 childAspectRatio，结果卡片要么扁成饼要么高成柱。正确做法是从设计稿上量尺寸，然后反推比例。

以两列卡片为例。假设屏幕内容区宽度是 360dp，页面左右内边距各 16dp，列间距 12dp，那么：

item 宽度 = (360 - 16 × 2 - 12) / 2 = 158dp

接着看设计稿给这个卡片的期望结构：顶部图片区高度 200dp，底部文字区高度 52dp，加起来总高 252dp。那么 childAspectRatio = 158 / 252 ≈ 0.627。

但这里有一个坑：这个比例是理想值，文字区高度 52dp 本身就包含字体行高在内。Flutter 里 Text 在不同系统默认字体下，行高会有细微差别，尤其鸿蒙的默认字体 HarmonyOS Sans 和 Android 的 Roboto 在 ascender（上伸部）和 descender（下伸部）上都不完全一致，导致同样字号的实际占位高度不同。所以算出来的 ratio 只能作为起点，最终必须以真机显示效果为准。

我的实操习惯是先给 ratio 留一点余量。比如算出来 0.627，先写 0.60，也就是把 cell 高度略微放大，跑一轮真机确认文字没有溢出后，再逐步收紧到 0.62、0.627。如果 item 内部有固定高度的图片区，用 Expanded 布局把文字区压缩到合理范围，这样即使 ratio 有细微偏差，也不太会触发 overflow 报错。

3. 核心实操：从默认网格到卡片化样式的完整落地

3.1 先搭一个能跑的基础网格

把所有样式的东西都剥掉，一个最小可运行的 GridView.builder 长这样：

Scaffold( backgroundColor: const Color(0xFFF5F6FA), body: GridView.builder( padding: const EdgeInsets.fromLTRB(16, 12, 16, 24), gridDelegate: const SliverGridDelegateWithFixedCrossAxisCount( crossAxisCount: 2, mainAxisSpacing: 12, crossAxisSpacing: 12, childAspectRatio: 0.62, ), itemCount: _items.length, itemBuilder: (context, index) { return _buildCard(_items[index]); }, ), )

为什么要强调 GridView.builder 而不是直接 GridView？因为 builder 是按需构建 item 的，它只构建视口附近看得见的那几个 cell，配合默认的 cacheExtent 预加载一部分，滑动时 item 会被复用，这和 ListView 的懒加载机制同源。而普通构造方法会把所有 item 一次性全部构建出来，数据量一上到几百，首帧就会明显卡顿，内存也被白白吃光。网格页的第一习惯就是 builder，没有例外。

3.2 卡片样式打磨：圆角、阴影、渐变蒙层与角标

基础网格能跑之后，接下来就是把默认的方格升级成有质感的产品卡片。这里我把完整实现贴出来，注释里直接写明每一步的原因：

Widget _buildCard(GridItemModel item) { return RepaintBoundary( child: Container( decoration: BoxDecoration( color: Colors.white, borderRadius: BorderRadius.circular(14), boxShadow: [ BoxShadow( color: const Color(0xFF2E3440).withOpacity(0.06), blurRadius: 10, offset: const Offset(0, 4), ), ], ), child: ClipRRect( borderRadius: BorderRadius.circular(14), child: Stack( fit: StackFit.expand, children: [ _buildImage(item.imageUrl), _buildGradient(), Positioned( left: 12, right: 12, bottom: 12, child: Text( item.title, maxLines: 1, overflow: TextOverflow.ellipsis, style: const TextStyle( color: Colors.white, fontSize: 16, fontWeight: FontWeight.w600, height: 1.2, ), ), ), if (item.tagText != null) Positioned( top: 10, right: 10, child: _buildTag(item.tagText!), ), if (item.isLocked) const Positioned.fill(child: _buildLockMask()), ], ), ), ), ); }

这个实现里有三个容易被忽略的细节：

第一，圆角容器里放图片必须套 ClipRRect。Container 的 borderRadius 只是画了圆角背景，并不具备裁剪能力。如果直接把 Image 放进去，图片四角会把圆角撑成直角，尤其在浅色背景下会非常明显。我在鸿蒙适配初期就因为这个被视觉同学单独拉了个会议，后来统一规范：带圆角的容器内如果有图片或不规则子控件，一律在外层包 ClipRRect。

第二，阴影参数要克制。移动端性能上，boxShadow 的 blurRadius 不要超过 10，spreadRadius 尽量用 0，阴影颜色用黑色加极低透明度，而不是直接给一个灰色。这样在鸿蒙上观感更柔和，也能明显减少 GPU 的重绘压力。我在鸿蒙真机上测试过，blurRadius 超过 15 时，滚动场景下帧率会有肉眼可感知的下降。

第三，渐变压暗层是文字可读性的关键。图片背景上直接叠白色文字，如果图片亮部恰好落在文字区域，文字就会看不清。这里用了一个从透明到黑色的线性渐变：

Widget _buildGradient() { return Positioned( left: 0, right: 0, bottom: 0, height: 72, child: DecoratedBox( decoration: BoxDecoration( gradient: LinearGradient( begin: Alignment.topCenter, end: Alignment.bottomCenter, colors: [ Colors.transparent, Colors.black.withOpacity(0.55), ], ), ), ), ); }

高度 72 是我实测下来比较舒服的值，能保证一行文字加底部留白都覆盖在渐变区内。

3.3 分隔线、间距和背景的氛围控制

并不是所有网格都适合卡片风格。像设置页九宫格、搜索历史标签这类入口型网格，更适合"无卡片、纯分割线"的表格形态。这种样式如果还用间距留白来做，页面会显得很散，这时候就要在 item 内部用 border 来画分隔线。

我的实现思路是：把 gridDelegate 的间距全部设为 0，在 item 内部用 Container 的 border 属性画右侧线和底部线，利用列号判断是否画右线：

Widget _buildCell(GridItemModel item, int index) { return Container( color: Colors.white, decoration: BoxDecoration( border: Border( bottom: const BorderSide(color: Color(0xFFEEF0F4), width: 0.7), right: index % 2 == 0 ? const BorderSide(color: Color(0xFFEEF0F4), width: 0.7) : BorderSide.none, ), ), child: ..., ); }

这样两列网格就能形成标准的表格线效果。用 border 方案而不是 CustomPaint，是因为 CustomPaint 需要自己算坐标，一旦 item 在滚动复用过程中位置变化，很容易画出错位线条，而 border 是跟随 cell 自身渲染的，不存在这种问题。这也是我踩过 CustomPaint 的坑之后才换回来的方案。

背景氛围方面，我的习惯是整个网格页统一一个浅色背景，item 间留白通过 spacing 和 padding 控制。如果网格里需要填充大面积色块，就要注意相邻 item 颜色不能完全一样，否则视觉上会粘成一团。可以给不同位置的 item 配置不同的底色层次，比如奇偶项交替浅白和浅灰，稍微拉开层次感。

3.4 下拉刷新、加载更多与空态处理

一个成熟的网格页，光有样式是不够的，交互闭环也得跟上。我通常会给网格页接三件套：下拉刷新、上拉加载、空态占位。

下拉刷新最直接，RefreshIndicator 包住 GridView 即可。鸿蒙上我实测过 Material 风格的 RefreshIndicator 是能正常工作的，四色转圈动画也完整，没有遇到渲染丢失的情况。如果你自己对动画要求高，可以自定义 indicator 组件，但默认方案已经足够稳妥。

上拉加载需要监听滚动位置。我在页面初始化时给 GridView 挂一个 ScrollController：

final ScrollController _controller = ScrollController(); void _onScroll() { if (_controller.position.extentAfter < 300) { _loadMore(); } }

extentAfter 表示当前视口底部距离内容最底部的像素长度。小于 300 说明用户快滑到底了，这时候触发加载下一页。这个阈值可以根据卡片高度调整：卡片越高，阈值适当调大，避免用户还没看到底部就触发加载导致体验突兀；卡片越矮阈值就调小一点，防止过度加载。

空态处理上，GridView 本身没法显示空态，所以要在外层判断数据源是否为空：

if (_items.isEmpty) { return const EmptyPlaceholder(text: '暂无数据，下拉刷新试试'); } return RefreshIndicator( onRefresh: _refresh, child: GridView.builder(...), );

注意这里有个细节：空态组件不能放在 GridView 内部，否则会被 builder 的懒加载机制吃掉，直接显示不出来。把空态放在外层和 GridView 平级，是最不容易出错的写法。

4. 鸿蒙环境下的差异化适配与性能调优

4.1 渲染层的差异：字体、阴影、按压反馈都要单独调

网格样式在鸿蒙上跑出问题，绝大多数集中在渲染层。第一个坑是字体行高。鸿蒙默认的 HarmonyOS Sans 和 Android 的 Roboto 在行高上存在差异，这就直接导致我在 Android 上算好的 childAspectRatio 拿到鸿蒙真机上出现文字底部被裁、甚至 overflow 报错。解决办法是在所有 Text 样式里显式指定 height，不依赖系统默认行高：

Text( item.title, style: const TextStyle( fontSize: 16, height: 1.25, ), )

显式指定 height 之后，文字占高就固定了，不管底层换什么字体，渲染结果都稳定。这个习惯建议从一开始就养成，否则换平台适配的时候会多出一堆莫名其妙的排版问题。

第二个坑是阴影渲染。OpenHarmony 的引擎对 BoxShadow 的模糊计算和 Android 不完全一致，我遇到过同一个阴影参数在 Android 上挺自然，到鸿蒙上就糊成一坨的情况。如果真机上发现阴影太糊，优先把 blurRadius 调小，或者干脆去掉阴影改用描边来勾勒层次感。阴影这种视觉装饰，在跨平台项目里越简单越安全。

第三个坑是按压反馈。InkWell 的水波纹在鸿蒙上有时不触发或者延迟明显。网格卡片没有按压缩放反馈会显得很迟钝，我采用的替代方案是用 AnimatedScale 做按压缩放，点击反馈清晰且实现简单：

GestureDetector( onTapDown: (_) => setState(() => _pressed = true), onTapUp: (_) => setState(() => _pressed = false), onTapCancel: () => setState(() => _pressed = false), child: AnimatedScale( scale: _pressed ? 0.96 : 1.0, duration: const Duration(milliseconds: 100), child: card, ), )

这个 0.96 的缩放比例是我调过几轮后的效果，既保留点击反馈又不显得卡片被"按塌"。

4.2 事件通道与平台视图的桥接

Flutter 页面跑到鸿蒙上之后，原生能力比如系统推送、扫码、相册选择，需要通过 MethodChannel 和 EventChannel 桥接。网格页里最常见的场景就是角标数字：比如"消息"宫格的红点数字来自原生推送，由鸿蒙侧实时推给 Dart。

EventChannel 接入非常直接：

static const EventChannel _badgeChannel = EventChannel('app/badge'); void _subscribeBadge() { _badgeChannel.receiveBroadcastStream().listen((event) { setState(() { _badgeCount = (event as num?)?.toInt() ?? 0; }); }); }

收到推送后更新数据源里对应 item 的 badgeCount，角标自然刷新。这套逻辑在 Android 和鸿蒙两端看起来完全一致，Dart 层不需要写任何平台分支判断。

PlatformView 的情况更复杂一点。网格 item 里最好不要直接嵌平台视图，比如网页视频、地图卡片这类。原因有两点：一是滚动时 PlatformView 会脱离 Flutter 视图树，轻则层级错乱，重则出现黑块闪烁；二是管理成本高，必须手动同步原生视图层级，性能损耗也不小。我的实践方案是：网格页用轻量占位图展示，点击后再跳转到原生页面或全屏页去加载真正的平台视图。这样既保住了网格滚动的流畅度，又规避了 PlatformView 的维护难题。

4.3 网格滚动性能优化清单

网格页面最怕滑起来掉帧。鸿蒙上 Flutter 引擎的整体表现已经不错，但网格本身的绘制开销还是需要专项优化。我这里有一份自己整理的检查清单，每一条都在实际项目中验证过：

• 优先用 GridView.builder，坚决不用一次性构建全部 item 的构造方式。
• 每个卡片套 RepaintBoundary。这一步的作用是让卡片自成一层渲染缓存，滚动时 GPU 不需要把整棵树重绘，只搬运对应层级的位图。卡片样式越复杂，收益越明显。
• 图片组件统一走缓存方案，并按需限制解码尺寸。一张 5000x3000 的大图直接丢进 GridView 的 cell，内存和 GPU 开销都非常大。给图片设置 cacheWidth 让引擎按展示尺寸压缩解码，能节省大量内存。
• itemBuilder 里避免创建不必要的对象。样式常量、TextStyle、BoxDecoration 这些尽量提为顶级常量或者放在 build 方法外部，否则每次构建 cell 都会重新创建对象，触发不必要的垃圾回收。
• 避免大量局部状态触发整个网格重建。点赞、收藏这类状态即时变化的，不要直接 setState 整个 GridView，而是针对单个 item 的状态做局部更新，或者把卡片组件用 const 构造并配合 IdleNotification 做更细粒度的控制。

// 图片限制解码尺寸的示例 CachedNetworkImage( imageUrl: item.imageUrl, cacheWidth: (158 * 2).toInt(), // 按 2 倍逻辑分辨率输出 fit: BoxFit.cover, )

这里的 158 就是前面算出来的 item 逻辑宽度，乘 2 是适配高 DPR 屏幕，既保证清晰度又避免解码过大的原图。当然，更合理的方式是通过 MediaQuery 拿到设备的 devicePixelRatio 再乘宽度，我这里为了直观直接用 2 倍。

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

5.1 溢出差错与间距不对的排查

网格开发里最经典的报错就是 "A RenderFlex overflowed by X pixels on the bottom"。这个报错十有八九是 childAspectRatio 算小了，cell 高度不够，内部内容被挤出边界。排查思路很简单：先把 ratio 往小调，也就是把 cell 高度放大，看报错是否消失。如果消失，说明比例确实不对，再逐步收紧到一个恰到好处的值。

还有一类问题是间距看起来不对。如果发现左右两列的间距和上下两卡片的间距明显不统一，先确认 gridDelegate 里的 mainAxisSpacing 和 crossAxisSpacing 值，再检查 item 内部有没有多余的 Padding。我见过不少人把间距写在 item 的 Padding 里，结果和外层 delegate 设置的间距叠加，视觉上间距忽大忽小。统一用 delegate 控制间距是长期来看最省心的约定。

分隔线不对齐也是高频问题。表格型网格如果出现竖线不在列之间，多半是 item 宽度计算时没有把列间距算进去，导致 border 的位置和实际 cell 边界错位。用 border 方案而不是间距方案时，一定要把 gridDelegate 的间距设为 0，所有间隔效果都由 item 内部 border 和背景色来承担。

5.2 图片加载与缓存问题

网格滚动时图片"闪跳"或者错位是最容易引发的客诉。我遇到过列表快速滑动后，部分格子的图片短暂显示成相邻格子的图，然后又跳回正确图片。这种现象基本可以锁定为图片组件的 key 没有绑定 item 唯一标识。

网格 item 复用机制会保留离屏的 cell，如果图片异步加载完成后没有正确对号入座，就可能出现错位。解决办法是在图片组件外层指定 key：

SizedBox( key: ValueKey(item.id), child: CachedNetworkImage(...), )

加上 ValueKey 之后，每个 cell 在复用时就能严格匹配对应数据，图片错位问题直接消失。这个坑我是在鸿蒙真机上抓到的，因为鸿蒙引擎的复用调度和 Android 有些细微差别，问题暴露得更频繁。

另外，如果网络图在快速滚动时大量重复加载，多半是缓存策略没生效。给图片设置合理的缓存宽度，并把图片包缓存组件的配置统一收敛到一个公共方法里，避免每处调用各写一套参数。

5.3 鸿蒙真机调试的几个坑

鸿蒙真机调试和 Android 调试有相似之处，但也有几个需要单独注意的地方。连接真机用的工具是 hdc，对应 Android 的 adb。连接好设备后，在 Flutter 工程目录执行 flutter attach，或者直接在 IDE 里选择 HarmonyOS 设备启动调试。我一开始没注意到这个差别，拿 adb 的命令去试，浪费了不少时间。

构建产物方面，鸿蒙的安装包是 HAP 格式，不是 APK。如果工程里配置了多平台构建，注意命令需要显式指定 OpenHarmony 平台目标，否则 Flutter 工具链默认还是会走 Android 构建，导致产物在鸿蒙设备上装不上。这个属于构建层面的问题，排查起来不算难，但第一次遇到时容易懵。

调试渲染问题还有一个实用技巧：鸿蒙设备上开启 Flutter 的调试着色可以快速定位 RepaintBoundary 是否生效。开启后每个 RepaintBoundary 都会被画上绿色边框，观察滚动时哪些区域在重复绘制，一眼就能看出需要加缓存的地方。

5.4 问题速查对照表

我把网格适配过程中遇到过、以及和同行交流收集到的典型问题整理成一张速查表，方便排查时直接对照：

6. 踩坑心得与后续扩展思路

整套方案落地之后，我心里最深的体会是：GridView 的自定义样式不是一个 item 好看就完事的问题，它是由比例计算、间距规划、渲染边界、字体行高、交互反馈共同构成的一个闭环。任何一个环节在鸿蒙上表现不一致，最终都会以某种视觉瑕疵暴露出来。所以跨平台适配项目一定要预留真机微调的时间，尤其是视觉归真这块，不能只靠模拟器验证，鸿蒙真机和 Android 真机各跑一遍才靠谱。

后面我还打算给这套组件扩展两个能力：一是支持跨列布局，做那种"一个大卡片加两个小卡片"的混合网格，这需要自定义 SliverGridDelegate 或者引入开源的地板流组件；二是把鸿蒙适配过程中沉淀的平台差异清单回收到团队内部的开发文档里，后续再有人接入新平台时，照着清单走一轮能省掉大量排查时间。

最后再分享一个我个人的小习惯：任何网格页面在改动样式后，先用一面纯色背景跑一遍，确认没有异常留白和错位，再切回正式数据。这个习惯帮我拦下了不少肉眼极难发现的问题，也推荐你试试。