写一次，用百次——鸿蒙自定义组件开发与复用的那些“小妙招”

作者：Echo_Wish

一、引子：当代码写到第三次复制粘贴时，心里就该警觉了

我相信很多开发者都经历过这样的瞬间：
你在鸿蒙项目里写UI，一次、两次、三次复制那段“固定样式的卡片组件”，心里嘀咕着：

“这玩意儿我昨天不是刚写过吗？”

没错，这就是重复劳动的警报信号。

鸿蒙开发中，特别是使用ArkUI（方舟UI）的声明式语法时，我们往往会为了赶进度而“先写出来再说”。但时间一长，UI重复代码堆成山，维护成本飙升。改个颜色要全局搜，改个交互要手动调。

这时候，你就该意识到：
👉 组件化才是正解。

今天这篇，我们就从“为什么要自定义组件”聊到“怎么复用更优雅”，再加上实战案例和一点“Echo_Wish式的开发哲学”。咱不搞虚的，干货直接上。

二、原理讲解：自定义组件，本质就是“封装思维”

先别急着敲代码，咱来捋清楚——自定义组件到底解决了啥问题？

简单说，鸿蒙的UI框架（ArkUI）是基于声明式编程模型的，你定义一个@Component，它就能像积木一样被拼到页面上。
这种设计特别适合构建“可复用、可维护、可独立演化”的UI单元。

举个例子：

• 你写了一个商品卡片组件；
• 在首页、推荐页、搜索页都要用；
• 如果哪天设计师说“卡片要圆角、要阴影、要点击动画”；
• 你只改组件，不用改三处代码。

这就是自定义组件的意义：

代码一次写好，逻辑一次封装，样式一次定义，处处可用。

而复用的核心，就是“抽象”——
别让业务逻辑和UI样式粘在一起，而是分层封装，参数化可配置。

三、实战代码：做一个可复用的“商品卡片组件”

咱直接动手写个例子。假设我们要在鸿蒙（ArkTS）中定义一个商品展示卡片。

@Component
export struct ProductCard {
  // 接收父组件传入的属性
  @Prop productName: string;
  @Prop price: number;
  @Prop imageUrl: string;
  @Prop onClick: () => void;

  build() {
    Column() {
      Image(this.imageUrl)
        .width('100%')
        .height(150)
        .borderRadius(12)
        .objectFit(ImageFit.Cover)

      Text(this.productName)
        .fontSize(18)
        .fontWeight(FontWeight.Medium)
        .margin({ top: 8 })

      Text(`￥${this.price}`)
        .fontSize(16)
        .fontColor(Color.Red)
        .margin({ top: 4 })
    }
    .padding(10)
    .borderRadius(12)
    .backgroundColor(Color.White)
    .shadow({ radius: 8, color: '#e0e0e0', offsetY: 4 })
    .onClick(() => this.onClick())
  }
}

这段代码非常直观：

• 使用@Component定义组件；
• 用@Prop接收外部参数；
• 内部用声明式语法定义结构与样式；
• 最后绑定点击事件。

然后在页面中使用时就非常简单：

ProductCard({
  productName: "鸿蒙智能手表",
  price: 1299,
  imageUrl: "/common/watch.png",
  onClick: () => { router.pushUrl({ url: "pages/detail" }) }
})

这就像搭积木一样。
一次定义，随处使用，清晰、优雅、无副作用。

四、场景应用：组件化思维让团队开发效率翻倍

组件复用最大的意义，不在于“少写几行代码”，而在于协作效率的提升。

想象这样一个场景：
公司要做一个“商城类App”，涉及多个页面：

• 首页推荐
• 商品列表
• 搜索结果
• 收藏夹

这四个地方都需要展示商品卡片。

如果每个开发者都各写一份，结果一定是：

• 样式不一致；
• 交互不统一；
• 一旦改设计，全员加班。

但如果有个统一的ProductCard组件库，就像刚才写的那样，
大家只要调用，不需要再造轮子。

甚至可以进一步抽象出“组件库模块化结构”：

/common
  ├── components
  │     ├── ProductCard.ets
  │     ├── EmptyState.ets
  │     ├── LoadingView.ets
  │     └── UserAvatar.ets
  ├── utils
  │     ├── formatPrice.ets
  │     ├── timeHelper.ets

这不仅提升了复用率，也让项目结构清晰、维护成本降低。

你甚至可以发布成一个内部组件库，通过npm或ohpm（OpenHarmony包管理器）来统一管理。
这样，真正实现了**“一次开发，全局复用”**。

五、Echo_Wish式思考：复用的不只是代码，更是思维

说点心里话。
我见过太多开发者忙着“写功能”，却很少花时间“写结构”。

其实，写代码是技术，写组件是思维。

当你开始有意识地去“复用”，你就在走向架构师的路上。
因为组件化的核心不是“减少工作量”，而是让系统可进化。

鸿蒙生态正在快速成长，从应用到设备、从UI到跨端能力，
未来一定是“组件驱动”的世界。
谁能把复杂的业务抽象成高内聚、低耦合的组件，
谁就能在鸿蒙的浪潮中游得更远。

另外，我特别喜欢一句话送给你：

“重复劳动是开发者的耻辱，复用能力是工程师的尊严。”

组件不仅仅是一块UI，更是一种理念。
当你把常用组件封装成库，分享给团队、社区甚至开源出去，
你会发现——写代码也能有“传承”的感觉。

六、结语：从写页面到写框架，是开发者的成长曲线

自定义组件的开发与复用，看似是小技巧，
其实是从“执行型开发”到“架构型思维”的一次跃迁。

在鸿蒙世界里，这种“积木式开发”理念，会让我们的工作更自由、更高效。