程序员Feri  | 13年编程老炮，拆解技术脉络，记录程序员的进化史

Hello，我是Feri。

在鸿蒙开发中，你是否遇到过这样的困惑：类型通用，但是又不想使用object，怎么办？

明明是处理列表数据，商品列表和用户列表的逻辑几乎一样，却要维护两份相似的代码？

这时候，ArkTS的“泛型”就能帮你解决这些问题。它不是什么高深莫测的语法，而是一种让代码“变通用”的实用工具。

今天我们就用通俗的方式聊聊，泛型在鸿蒙开发中到底有什么用，以及为什么它能让你的开发效率翻倍。

一、泛型是什么？用一个生活例子讲明白

泛型的核心思想很简单：“定义的时候不指定具体类型，使用的时候再确定类型”。

举个生活中的例子：我们平时用的快递箱，在生产时不会规定只能装衣服或电子产品——它是一个“通用容器”，装衣服时它就是“衣服快递箱”，装手机时它就是“手机快递箱”。

这个“通用容器”的设计思路，就是泛型的本质。

在ArkTS中，泛型就像这个“快递箱”：你可以定义一个“通用组件”或“通用工具”，不限制它处理的数据类型，等到实际使用时，再告诉它“现在要处理用户数据”“现在要处理商品数据”。

二、为什么鸿蒙开发离不开泛型？

鸿蒙生态的特点是“多设备、多场景”——同一套应用可能要跑在手机、手表、车机等不同设备上，处理的数据类型五花八门（如传感器数据、用户信息、设备状态等）。

泛型的价值，就在于让代码能灵活适配这些差异，同时保证类型安全。

具体来说，它能解决鸿蒙开发中的三个核心问题：

1. 避免重复开发，提升代码复用率

鸿蒙开发中，很多UI组件（如下拉框、列表项）或工具逻辑（如数据筛选、状态管理）的核心功能是一样的，只是处理的数据类型不同。

比如一个“列表项组件”：展示用户信息时需要显示“姓名+年龄”，展示商品时需要显示“名称+价格”。

如果不用泛型，你可能要写两个组件（UserListItem和ProductListItem）；但用泛型，你可以定义一个GenericListItem，让它根据传入的数据类型自动适配展示逻辑——一次编写，两处复用。

2. 保证类型安全，减少运行时错误

鸿蒙应用对稳定性要求很高（尤其是设备端开发），而类型错误是导致崩溃的常见原因。

比如你定义了一个“设备状态列表”，本意是只放“设备对象”，如果不小心传入了一个“字符串”，没有类型约束就可能在运行时出错。

泛型能在编译阶段就帮你“把关”：它会明确要求“这个列表只能放设备对象”“那个下拉框只能选数字类型”，不符合类型的操作会直接报错，从源头避免错误。

3. 适配多设备场景，应对数据多样性

鸿蒙设备的硬件差异很大：手机可能需要处理复杂的用户信息，智能手表可能需要处理传感器的数值（如心率、步数），车机可能需要处理车辆状态（如速度、油量）。

这些数据类型差异很大，但处理逻辑（如“展示在列表中”“存储到本地”）可能完全相同。

泛型能让你用一套逻辑兼容所有类型——比如一个“本地存储工具”，既能存用户信息，又能存传感器数据，不用为每种设备重写存储逻辑。

三、泛型在鸿蒙开发中的3个典型场景

不用代码，我们也能看懂泛型在实际开发中的作用：

1. 工具类中好用的很！

比如我们进行关系型数据库操作的时候，自动解析ResultSet为泛型，在2操作Api接口解析接口返回值，比如R类等等

export class ObjectUtil {
  /**
   * 把对象转换为 键值对拼接形式*/
  static parsekv<T>(obj: T): string {
    let res: string = '';
    let data=obj as object as Record<string,Object>;
    let arr=Object.entries(data);
    for (let i = 0; i < arr.length; i++) {
      if(arr[i][1]==null || arr[i][1]=='' || arr[i][1]==0){
        continue;
      }
      res+=arr[i][0]+'='+arr[i][1]+"&";
    }
    if(res.length>0){
      res=res.substring(0,res.length-1);
    }
    return res;
  }
}

2. 状态管理：让数据操作更安全

鸿蒙的状态管理（如@State、@Link）是UI交互的核心。

如果状态变量的类型不明确，很容易出现“把字符串赋值给数组”“把数字赋值给对象”的错误。

泛型能给状态管理加一层“保护罩”。比如你定义了一个“购物车状态容器”，用泛型指定它只能放“商品对象”，那么：

• 当你试图添加一个“用户对象”时，编译器会直接报错；
• 当你修改商品数量时，泛型会确保你传入的是数字（而不是字符串）。

这样一来，状态操作的安全性大幅提升，尤其是在大型项目中，能减少很多难以排查的BUG。

export interface R<T> {
  code:number;
  msg:string;
  data:T;
}

3. 长列表渲染：高效适配不同数据类型

鸿蒙中长列表（如联系人、商品列表）必须用LazyForEach实现懒加载（只渲染屏幕内的项，提升性能）。

但列表的数据类型可能千差万别：有时是用户列表，有时是订单列表，有时是设备列表。

泛型可以让LazyForEach的数据源“通用化”：定义一个GenericDataSource，无论传入的是用户、订单还是设备数据，它都能按照相同的逻辑实现懒加载。

不用为每种数据类型写一个数据源，既节省代码，又保证了列表渲染的高效性。

四、泛型不难，关键是理解“通用”的价值

很多小伙伴会觉得泛型“复杂”，其实是因为一开始就陷入了语法细节。

但从鸿蒙开发的实际场景来看，泛型的核心价值很简单：用一套逻辑解决多类型问题，同时保证安全。

它就像一把“万能钥匙”：不是说它能打开所有锁（而是通过“适配不同锁芯”来打开不同的锁）；也像一个“标准接口”：无论接入的数据是什么类型，只要符合接口规范，就能被统一处理。

在鸿蒙生态越来越庞大的今天，设备、场景、数据类型会越来越多样。

学会用泛型，能让你的代码更灵活、更稳定，也能让你在多设备开发中少走很多弯路。

最后：泛型不是“炫技”，而是“实用工具”

别把泛型当成必须掌握的“高深语法”，而要把它看作提升开发效率的“实用工具”。

在鸿蒙开发中，当你发现“这段代码改改类型就能再用一次”时，不妨试试用泛型——它会让你少写很多重复代码，也会让你的应用更稳定、更易维护。

下次开发鸿蒙应用时，想想那个“通用快递箱”的例子：你的组件、工具、状态管理，能不能也做成“通用容器”？这就是泛型的意义。