前段时间接到一个活儿把 Flutter 项目里大量用到的 collection 三方库迁移到鸿蒙运行时上。一开始我不以为然——这玩意儿是个纯 Dart 包不碰 FlutterEngine、不碰平台通道需要什么适配真跑起来才发现“纯 Dart 包换个壳就能跑”在很多场景下只是错觉尤其是当你开始较真深度相等判别、增强型数据结构这类逻辑时鸿蒙侧与 Dart 侧在很多底层行为上并不一致。这篇文章就把我这次适配的完整过程、选型思路和最终沉淀下来的架构方案摊开讲给同样在搞 Flutter/鸿蒙 双端或者 ArkTS 迁移的同学做个参考。先交代背景。我手里是一个典型的跨端业务模块列表筛选、配置合并、结果去重这些逻辑几乎全靠 collection 包撑着。collection 是 Dart 官方维护的得力工具集提供了一批开箱即用的扩展方法和数据结构代码写起来非常舒服。而这次目标平台是鸿蒙生态问题就来了鸿蒙世界里没有 Dart VM除非你愿意为 Flutter 单独搭建一套运行时容器否则所有依赖 collection 的逻辑都要在 ArkTS 环境里重来一遍。于是就有了这篇文章的主题在把 collection 的增强数据结构和深度相等逻辑搬到鸿蒙侧的过程中我踩了哪些坑、做了哪些取舍以及最后怎么把它组织成一套可控的复杂逻辑架构。1. 为什么一个纯 Dart 包也要谈“鸿蒙化”1.1 collection 包在我项目里的真实分量很多 Flutter 开发者对 collection 的印象是“一个提供了几个扩展方法的工具库”平时用groupBy、firstWhereOrNull觉得很方便但从来没把它当回事。等到要跨平台迁移时才知道它到底藏了多少细节。在 package:collection 里我最常用的功能可以分成三类。第一类是 Iterable 扩展比如groupBy、nonNulls、mapIndexed、firstWhereOrNull这些它们让集合操作少写很多 for 循环。第二类是特殊容器比如QueueList、CanonicalizedMap、LruMap它们解决了普通 List/Map 在某些场景下性能或者语义不匹配的问题。第三类是相等性框架Equality、ListEquality、MapEquality和最重要的DeepCollectionEquality这是做复杂对象比较、单元测试断言、状态变更检测的利器。这些功能通常在 Dart 侧用得很顺手因为它们和语言本身的运行时绑定得很深。比如CanonicalizedMap依赖的是传入的equals/hashCode回调而不是对象自带的实现QueueList依赖的是 Dart 对 List 和 Queue 双接口的抽象。一旦你把这些代码从 Dart 世界搬到 ArkTS 世界问题就全出来了ArkTS 的 Array 没有这些扩展方法Map/Set 的迭代语义不完全一致更没有一套统一的 Equality 抽象。于是“鸿蒙化适配”这个命题就成立了。1.2 “鸿蒙化”不止一种含义先分清场景再动手我踩的第一个坑是没搞清楚“鸿蒙化”到底指什么。这个说法在不同团队里含义完全不同至少可以分成三种场景。第一种场景是“让 Flutter 应用跑在 OpenHarmony 上”。社区和厂商已经有不少 OpenHarmony 的 Flutter 适配分支它们补全了 Flutter Engine 在鸿蒙设备上的平台通道让现有 Flutter 代码可以直接打进鸿蒙包。这种情况下collection 作为纯 Dart 库理论上会被直接编译进产物只要 Dart 版本兼容你几乎不用改代码。这里的“适配”更多是验证、锁版本、补测试工作量不大。第二种场景是“鸿蒙 NDK 原生 ArkTS 应用”。HarmonyOS NEXT 的官方推荐开发语言是 ArkTS它没有 Dart 运行时Flutter 代码不能直接运行。你只能把业务逻辑翻译成 ArkTS。这个时候collection 里所有被你依赖的数据结构和比较算法都需要重新实现一遍。这是真正的重写也是我这次做的主要工作。第三种场景是跨端共享核心逻辑。把 groupBy、深度相等这类逻辑下沉到 C/RustDart 和 ArkTS 都只做薄封装。这种做法前期成本最高但因为核心算法与语言无关后续不管 Flutter 还是鸿蒙侧升级都只需要重新绑定一层接口。为什么一上来就要分场景因为不同场景下“适配 collection”这件事的边界完全不同。如果你不先想清楚很容易一上来就动手写 ArkTS 版本的 DeepCollectionEquality结果发现项目其实只需要方案一的版本锁定白费了一堆功夫。1.3 Dart 运行时与 ArkTS 的底层行为差异在真正动手前我建议你先建立一张“行为差异清单”。以下是同一段逻辑在 Dart 和 ArkTS 里最典型的偏差。首先是 Map 的迭代顺序。Dart 的LinkedHashMap默认按插入顺序迭代collection 里很多扩展方法都隐含这个语义比如groupBy返回的 Map键的顺序就是第一次出现时的顺序。ArkTS 的Map虽然也保持插入顺序但如果你用对象字面量{}来代替 Map顺序规则就完全不一样了。所以迁移时不能简单地把 Dart Map 换成一个普通 Object。其次是相等性与哈希契约。Dart 里所有对象都有和hashCodecollection 的 Equality 框架靠它们工作。ArkTS 虽然也有但对象比较的语义、数组和 Map 的深比较行为都不同而且没有统一的 Equality 抽象层。你在 Dart 里写const DeepCollectionEquality().equals(a, b)只是一行代码到了 ArkTS 里必须从零设计比较器的扩展点。最后是泛型和空安全。collection 新版本已经全面拥抱空安全返回值经常是T?。ArkTS 支持可空类型但对泛型边界、类型推断的限制比 Dart 严格得多。比如groupByT, K这种泛型函数在 Dart 里很自然在 ArkTS 里就要小心泛型参数不能用于某些运行时操作否则编译器会直接报错。这些差异决定了你后续的移植工作量。理解它们才能把“适配”这件事做得可控。2. 增强型数据结构拆解哪些值得原样搬哪些必须换写法2.1 高频扩展方法groupBy 与 firstWhereOrNull 的 ArkTS 落地按我的实际统计业务代码里使用频率最高的 collection 功能就那几个groupBy、nonNulls、firstWhereOrNull、mapIndexed。它们本质上是语法糖不依赖特殊的数据结构所以在 ArkTS 里最容易移植也最值得优先搞定。Dart 侧原来是这样写的import package:collection/collection.dart; final words [apple, banana, avocado, blueberry]; final grouped words.groupBy((w) w[0]); // {a: [apple, avocado], b: [banana, blueberry]} final first words.firstWhereOrNull((w) w.startsWith(b)); // banana final nonNullValues [1, null, 2, null, 3].nonNulls.toList(); // [1, 2, 3] final indexed words.mapIndexed((i, w) $i: $w).toList();到了 ArkTSArray 上并没有这些扩展。一个务实的做法是不去模仿 Dart 的扩展语法而是直接提供顶层函数把数据源作为第一个参数传入export function groupByT, K(items: T[], keySelector: (item: T) K): MapK, T[] { const result new MapK, T[](); for (const item of items) { const key keySelector(item); const list result.get(key); if (list undefined) { result.set(key, [item]); } else { list.push(item); } } return result; } export function firstWhereOrNullT(items: T[], predicate: (item: T) boolean): T | null { for (const item of items) { if (predicate(item)) { return item; } } return null; } export function nonNullsT(items: ArrayT | null | undefined): T[] { const result: T[] []; for (const item of items) { if (item ! null item ! undefined) { result.push(item); } } return result; } export function mapIndexedT, R(items: T[], mapper: (index: number, item: T) R): R[] { const result: R[] []; for (let i 0; i items.length; i) { result.push(mapper(i, items[i])); } return result; }这个迁移几乎没有成本但有几个细节要注意。一是groupBy的返回类型ArkTS 的MapK, T[]等同于 Dart 的MapK, ListT语义和迭代顺序都能对上。二是firstWhereOrNull在 Dart 里是T?在 ArkTS 里对应T | null这里不要用undefined去混用ArkTS 对null和undefined的区分非常严格建议团队统一只用null表示“不存在”。三是性能ArkTS 的 Array 操作是内置的这些函数只要不搞出 O(n²) 的嵌套遍历一般都没问题。2.2 特殊容器QueueList、CanonicalizedMap、LruMap 的取舍相比扩展方法collection 里的特殊容器才是真正需要动脑子的地方。QueueList是一个同时实现 List 接口和 Queue 接口的容器底层用循环数组实现所以在队首插入删除也是 O(1)而普通 List 在队首删除是 O(n)。如果你的业务里有大量“从列表头部取数据、尾部加数据”的场景比如一个实时日志缓冲队列Dart 里用QueueList很舒服。ArkTS 这边没有现成的等价物你有两个选择如果数据量不大直接Array加shift/push就够了代码简单如果数据量很大、性能敏感就得自己封装一个环形缓冲区这属于基础设施级的活不要临时抱佛脚最好放进公共库统一维护。CanonicalizedMap的语义是“用外部传入的 equals 和 hashCode 来决定键的唯一性”最常见的用途是你有一批对象希望按某个字段去重但又不愿意改对象自身的。比如一组用户对象你想按 userId 合并UserId 重复时保留后出现的版本。Dart 里直接传两个回调就行final map CanonicalizedMapString, User( equals: (a, b) a b, hashCode: (key) key.hashCode, );ArkTS 的 Map 不支持自定义键相等逻辑要不你用普通 Map 先处理后去重要不就自己包一层。我的建议是不要去仿照 CanonicalizedMap 做通用实现因为 ArkTS 的泛型和回调机制写这种通用容器会非常别扭直接用“先取 key 再 set”的方式改写业务代码反而更清晰。LruMap同理LRU 缓存逻辑本身不复杂但要做得通用并且线程安全工作量不小。迁移时先看场景如果只是缓存网络响应或者图片信息完全可以用有限的普通 Map 加时间戳淘汰或者直接找鸿蒙生态里现成的缓存库没必要把 collection 的所有轮子都搬一遍。2.3 ArkTS 等价物怎么设计按需实现避免整套照搬我在迁移过程中犯过的一个错误是试图在 ArkTS 里把 collection 的 API 完整复刻一遍做一个“ArkTS 版 collection”。做了三天就放弃了因为成本高、收益低而且很多 Dart 的抽象在 ArkTS 里根本没法无损表达。更实际的做法是“按需实现”。先扫描整个 Flutter 项目的import package:collection/collection.dart把用到的每一个 API 列成一张表统计出现次数和对应业务模块。然后只对这些 API 写 ArkTS 实现剩下的碰都没碰。这样你迁移的是一份“使用清单”而不是整个库。拿我那个项目来说groupBy用了 20 多处DeepCollectionEquality用了 10 多处QueueList只用了 1 处LruMap和CanonicalizedMap根本没用到。那么 ArkTS 侧就只需要实现扩展方法那批工具函数外加一个深度相等比较器。QueueList 那 1 处最后是用普通 Array 重写的因为它的调用点确实不太在意队首删除的复杂度。这就是“合适比完整更重要”。3. 深度相等判别实战DeepCollectionEquality 的原理与移植3.1 默认 为什么不够用“深度相等”这个需求凡是做配置合并、接口 diff、状态比对的人都绕不开。Dart 里两个内容完全相同的 Map用比较结果是 false因为默认的相等是引用相等。我最早是在单元测试里遇到这个问题的一个方法返回了嵌套两层以上的 Map我想断言它和期望值相等直接expect(actual, expected)失败翻遍错误日志才发现是引用不同内容明明一模一样。collection 给出的答案是DeepCollectionEquality。它不比较引用而是递归地比较 List、Map、Set 的每一项最后落到基础类型上才用。这套逻辑在 Flutter 开发里帮了大忙测试断言、状态管理 diff、缓存 key 生成、对象快照比对都能用。3.2 DeepCollectionEquality 的核心实现逻辑想要在鸿蒙侧移植就得先把它拆明白。DeepCollectionEquality本身并不神秘它本质上是一个递归比较器核心决策可以概括成四步。第一步是快速失败。如果两个对象引用相同直接返回 true如果其中一个是 null 而另一个不是直接返回 false。这个优化能省掉绝大多数无意义的递归。第二步是类型分派。如果 a 和 b 都是 List就按顺序逐个比较元素如果都是 Map先比 size再逐个键比较值如果都是 Set采用无序比较——这也是最容易写错的点因为 Set 里的元素没有顺序直接按 List 方式比就会误判。实际实现里Set 的深度比较要找到“每个 a 中的元素都能在 b 中找到一个未匹配的相等元素”复杂度会明显上升。第三步是递归。对 List 里的每个元素、Map 里的每个值、Set 里的每个成员只要它们还是集合类型就进入下一层比较。这个过程一直持续到遇到基础类型比如字符串、数字、布尔值这时候用的才是普通的。第四步是防环。如果一个对象里存在循环引用比如a.list [a]直接递归会无限循环直到栈溢出。DeepCollectionEquality内部会记录当前比较路径上已经见过的对象对如果再次遇到相同的组合就直接认为相等从而避免死循环。理解了这四步你就不难发现深度等比的难点不在“递归”而在“类型分派”和“防环”。这两个点决定了移植后的正确性。3.3 ArkTS 移植与环引用防护我在 ArkTS 里写的第一版深度相等就是没处理“Set 无序”和“循环引用”两个问题结果业务数据里一出现循环引用就爆栈。下面这个实现是第二版也是我目前在用的版本处理了 List、Map、Set 和普通对象并加入了环引用防护。export class DeepEquality { private readonly visited new WeakMapobject, WeakSetobject(); reset(): void { this.visited new WeakMapobject, WeakSetobject(); } equals(a: object, b: object): boolean { if (a b) { return true; } const stackKey this.markAndCheckVisited(a, b); if (stackKey) { return true; } if (Array.isArray(a) Array.isArray(b)) { return this.equalsArray(a, b); } if (a instanceof Map b instanceof Map) { return this.equalsMap(a, b); } if (a instanceof Set b instanceof Set) { return this.equalsSet(a, b); } return this.equalsObject(a, b); } private equalsArray(a: unknown[], b: unknown[]): boolean { if (a.length ! b.length) { return false; } for (let i 0; i a.length; i) { if (!this.equals(asObject(a[i]), asObject(b[i]))) { return false; } } return true; } private equalsMap(a: Mapunknown, unknown, b: Mapunknown, unknown): boolean { if (a.size ! b.size) { return false; } for (const [key, value] of a) { if (!b.has(key)) { return false; } if (!this.equals(asObject(value), asObject(b.get(key)))) { return false; } } return true; } private equalsSet(a: Setunknown, b: Setunknown): boolean { if (a.size ! b.size) { return false; } const unmatched new Set(b); for (const item of a) { let found false; for (const candidate of unmatched) { if (this.equals(asObject(item), asObject(candidate))) { unmatched.delete(candidate); found true; break; } } if (!found) { return false; } } return true; } private equalsObject(a: object, b: object): boolean { const keysA Object.keys(a); const keysB Object.keys(b); if (keysA.length ! keysB.length) { return false; } for (const key of keysA) { if (!Object.prototype.hasOwnProperty.call(b, key)) { return false; } if (!this.equals(asObject(a[key]), asObject(b[key]))) { return false; } } return true; } private markAndCheckVisited(a: object, b: object): boolean { let setA this.visited.get(a); if (setA undefined) { setA new WeakSetobject(); this.visited.set(a, setA); } if (setA.has(b)) { return true; } setA.add(b); return false; } }这个版本用了WeakMap来记录“已经访问过的对象对”避免循环引用导致栈溢出。等于是把 Dart 内部那套防环逻辑用 JS/TS 的方式重新表达了一遍。但移植到真正的 ArkTS 编译环境时你可能会遇到两个问题一是 ArkTS 某些版本对WeakMap和WeakSet的支持度不确定如果编译器不支持就需要退化方案比如给每个对象分配一个自增 id然后用Mapnumber, Setnumber来记录。二是 ArkTS 对object类型的索引访问限制很严a[key]这种写法有时需要先断言成Recordstring, object之类的类型这个要在实际工程里根据 ArkTS 编译器的报错去调整。3.4 移植后的性能调优与使用边界深度相等这东西功能做对了只是第一步性能才是真正考验工程能力的地方。我自己在鸿蒙侧跑完一轮性能测试后有三个调优点非常有效。第一个调优点是大数据量集合的快速失败。比较两个各有上万条记录的 Map 时如果它们的 size 都不同那就完全没必要继续递归直接返回 false。这个在 equalsMap 里我已经加了List 和 Set 也要记得加。第二个调优是避免“无意义”的深度比较。很多业务场景里你其实只需要比较一层或者两层不用一路递归到底。可以给 DeepEquality 加一个maxDepth参数超过深度直接认为相等或者通过 hashCode 快速判断。我实际项目里就把深度限制设成了 8足够覆盖配置对象的嵌套层次同时避免极端数据把调用栈压垮。第三个调优是外层缓存。同一个对象可能被反复比较比如列表 diff 的时候。如果在 DeepEquality 外面包一层带 hash 的缓存把已经比较过的对象对结果记下来后续直接命中缓存能省掉大量重复递归。但要注意的是缓存 key 必须包含两个对象的版本信息否则对象内容变了缓存还命中就会产生很隐蔽的错误。所以我在工程里只在明确不会变化的对象上启用了这个缓存其余情况老实每次全量比。还有一个使用边界必须说清楚DeepCollectionEquality 对普通对象是“按 keys 数量快速比较 逐个递归”它并不知道你业务对象的业务语义。如果你有一个对象里面有id和updateTime两个字段但你只关心id是否相等就不应该用深度相等去比较整个对象那会很浪费。这种场景应该自己写一个ByIdEquality或者在比较器里加一个自定义字段列表。4. 鸿蒙化路径选型跑 Flutter 容器还是重写 ArkTS4.1 方案 A让 Flutter 直接跑在 OpenHarmony 上先说工作量最小的路线。OpenHarmony 社区里已经有 Flutter 引擎的移植版本可以让 Flutter App 直接运行在鸿蒙设备上。这个方案下collection 是纯 Dart 包不依赖任何平台通道因此理论上直接就能跑。我在验证阶段试过只要 pubspec 里锁定的 collection 版本和你使用的 Dart SDK 版本匹配编出来的 HAP 包完全没问题。但“能用”和“好维护”是两回事。这个方案的代价是你的应用体积会大不少因为 Flutter Engine 本身要打进去启动性能和原生 ArkTS 应用相比也有差距Flutter 引擎移植分支的版本更新、崩溃稳定性、三方插件兼容性这些都要团队持续投入跟进。所以方案 A 更适合“短期快速上架”或者“团队本来就是 Flutter 主力”的情况。4.2 方案 BArkTS 重写 collection 核心层方案 B 就是我最终选的路线。HarmonyOS NEXT 原生应用现在主推 ArkTS如果业务要长期在鸿蒙生态里生根把核心逻辑用 ArkTS 重写是绕不开的。但这里有一个容易被低估的事实你重写的不是 collection 这个库而是你“对 collection 的使用方式”。这也是我在前面反复强调“按需实现”的原因。重写的时候我建议按这个顺序来先把所有import package:collection/collection.dart的地方全部找出来按功能分类然后先写扩展方法那一批纯函数因为它们最简单、通用性最强接着写深度相等比较器这是技术含量最高的部分最后再决定哪些特殊容器需要保留。整个重写过程不追求 API 一致只追求“结果一致”所以函数签名、参数顺序都可以按照 ArkTS 的习惯来。4.3 方案 C逻辑下沉到 C/Rust 再跨端绑定如果你的团队同时维护 Flutter、鸿蒙、可能还有 iOS/Android 原生多个端而且核心集合逻辑非常复杂那方案 C 值得考虑。把 groupBy、深度相等、优先级队列这些算法抽到一个 C/Rust 库里Dart 通过 FFI 调用ArkTS 通过 NAPI 调用两边都只有一层薄薄的绑定代码。这样最主干的逻辑只要维护一份跨端一致性也最好。但方案 C 的工程门槛很高。FFI 和 NAPI 的绑定要处理内存生命周期、异常传播、异步回调不是随便写几行就能稳定的。我之前在另一个项目里试过 C 方案光是把 Dart 的Map转成 C 的unordered_map再传回结果就花了不少时间。所以这个方案更适合“核心算法已经足够稳定且确实需要跨三端以上共享”的场景。4.4 决策表与分析方案适用场景工作量风险点我的建议A. Flutter 跑在 OpenHarmony快速迁移现有 Flutter App团队以 Dart 为主低引擎体积大、启动性能弱、跟随上游版本较被动短期过渡或验证可行B. ArkTS 重写 collection 核心鸿蒙原生应用长期发展需要控制包体中高需要准确理解 Dart 语义差异防环和泛型易踩坑鸿蒙 NEXT 原生业务的首选C. C/Rust 下沉多端共享复杂算法跨端一致性要求极高高绑定层复杂、调试困难算法非常稳定后再上我这次选择方案 B是因为目标产品是鸿蒙侧的原生应用团队不想为一个工具库拖进整个 Flutter 引擎也不想为了几个数据结构去养一套 C 绑定。事实证明按需重写的成本比预想低一些因为真正高频使用的 collection 功能并不算多。但如果你只是想让现有 Flutter 应用快速在鸿蒙设备上跑起来方案 A 的性价比显然更高。5. 复杂逻辑架构设计与踩坑实录5.1 用门面模式隔离 collection 依赖鸿蒙化做完之后我复盘整个项目发现一个最值得推广的经验在业务代码和 collection 之间加一层门面而不是在几十个文件里直接import package:collection/collection.dart。Dart 侧可以先定义这样一个门面类// app_collection.dart import package:collection/collection.dart; class AppCollection { static MapK, ListT groupByT, K( IterableT items, K Function(T) key, ) { return items.groupBy(key); } static bool deepEquals(Object? a, Object? b) { return const DeepCollectionEquality().equals(a, b); } static T? firstWhereOrNullT( IterableT items, bool Function(T) test, ) { return items.firstWhereOrNull(test); } }所有业务代码只依赖AppCollection不直接依赖 collection。等迁移到 ArkTS 时ArkTS 侧对应地写一个几乎同名的静态类export class AppCollection { static groupByT, K(items: T[], key: (item: T) K): MapK, T[] { return groupByImplT, K(items, key); } static deepEquals(a: object, b: object): boolean { return new DeepEquality().equals(a, b); } static firstWhereOrNullT(items: T[], test: (item: T) boolean): T | null { return firstWhereOrNullImplT(items, test); } }这样迁移时业务层代码基本不用动只需要把底层实现从 collection 换成 ArkTS 版本。这套门面模式听起来简单但效果极好。我见过太多鸿蒙化项目因为没有这层隔离最后import package:collection散落在三十几个文件里改起来就是一场大型重构。早做隔离后面能省掉一个星期的救火时间。5.2 泛型、空安全与环引用三个最典型的坑迁移时真正让我抓狂的坑有三个每一个都值得单独说。第一个坑是泛型边界。Dart 里groupByK的 K 可以是任意类型包括Map、List这些引用类型。ArkTS 的泛型函数对类型参数的使用有很多限制比如你不能在泛型函数内部直接用keySelector(item)的返回值去作为Map的键编译器可能会报“泛型类型不能用于索引”之类的错误。解决方法是把键的类型收敛成string | number或者在函数签名处给泛型加上边界约束。这个坑不致命但会让你在编译期反复试错。第二个坑是空安全语义。collection 1.17 之后的版本全面空安全意味着firstWhereOrNull返回的T?在 ArkTS 里对应T | null。看起来简单但实际代码里有一个特别容易踩的误区Dart 里null和undefined都可以表示“无”而 ArkTS/TS 世界里大家经常不自觉地把两者混用。一旦某个函数返回了undefined另一个函数又用 null去判断就会漏判。我在鸿蒙侧定了一条铁律所有 collection 相关函数统一用null表示“无”禁止返回undefined这样跨函数传递时心智负担小很多。第三个坑就是前面提到的环引用。深度相等比较器没有防环措施时遇到自引用对象直接栈溢出。我第一版 ArkTS 实现就栽在这里排查了半天最后发现是一份测试数据里构建了obj.self obj。补上WeakMap防环之后问题才算根除。这里提醒一句如果鸿蒙侧的 ArkTS 编译器限制太多没法用WeakMap退而求其次的方案是“限制最大递归深度”超过深度直接抛异常。虽然不够优雅但至少不会静默死循环。5.3 单元测试怎么迁移从 Dart 测试到 ArkTS 测试做鸿蒙化适配最容易被砍掉的工作就是测试迁移。很多人觉得“逻辑我都实现了测试差不多就行”但我的经验恰恰相反这轮迁移里单元测试才是帮你发现语义差异的核心手段尤其是深度相等这种递归逻辑不测根本不敢上生产。Dart 侧的测试原本长这样import package:test/test.dart; import package:collection/collection.dart; void main() { test(deep equality should compare nested map, () { final a {list: [1, 2, {x: 3}]}; final b {list: [1, 2, {x: 3}]}; expect(const DeepCollectionEquality().equals(a, b), isTrue); }); }到了鸿蒙侧的 ohos 测试框架思路完全一致只是 API 换成了 hypiumimport { describe, it, expect } from ohos/hypium; import { DeepEquality } from ../src/main/ets/collection/DeepEquality; describe(DeepEqualityTest, () { it(shouldEqualNestedMap, () { const a { list: [1, 2, { x: 3 }] }; const b { list: [1, 2, { x: 3 }] }; expect(new DeepEquality().equals(a, b)).assertTrue(); }); it(shouldHandleCycleReference, () { const a: Recordstring, object {}; const b: Recordstring, object {}; a.self a; b.self b; expect(new DeepEquality().equals(a, b)).assertTrue(); }); });我建议把 Dart 侧测试用例直接“翻译”到 ArkTS至少保证核心场景一一对应。比如深度相等要覆盖嵌套 Map、嵌套 List、Set 无序、基础类型相等与不等、循环引用、空 Map/List、超大集合性能冒烟。这些用例在 Dart 侧已经验证过你的业务逻辑搬到 ArkTS 侧如果失败很大的概率不是业务问题而是适配器语义差异。最后再分享一个我个人的操作体会不要因为 collection 是官方库就觉得鸿蒙化适配一定很简单。真正决定工作量的不是包本身而是你业务代码里对它的使用方式。如果你像我一样业务逻辑里大量使用 groupBy 和 DeepCollectionEquality那么先在 Dart 侧抽一层门面、把所有入口收拢到一处后续无论是跑 OpenHarmony 容器还是 ArkTS 重写代价都会小很多。这是我这次踩完坑之后最后悔没早点做的事。
