开头：为什么做这个

HDS（HarmonyOS Design System）强调的是跨设备、跨场景的一致视觉体验与设计品质。
在实际开发中，我遇到一个很典型的问题：沉浸光感材质效果目前主要依赖 HdsTabs 的悬浮态能力，官方没有给出可直接复用的自定义 Button 组件和对应材质接口。

这带来两个现实痛点：

• 想做统一 HDS 风格的浮动操作入口时，重复造轮子成本高
• 业务项目里容易出现“每个页面都自己拼一版”的视觉不一致

所以这次我做了两件事：在现有能力边界内完成组件化封装，并尝试发布到 ohpm 三方库，让更多开发者可以直接复用。

正文：怎么做的

第一步：确认能力边界，先不做“万能组件”假设

我先把边界讲清楚：当前材质能力来自 HdsTabs 的 barFloatingStyle，并不是通用于任意容器的独立材质按钮接口。
因此思路不是“重新发明一个材质系统”，而是基于已稳定的 HDS 能力做可复用封装。

第二步：围绕常见场景做组件封装

组件提供了高频配置能力（尺寸、图标、材质、布局、事件、内容槽位），并保持默认即用。
下面 4 张 GIF 分别对应真实示例场景：

1) 开箱即用：基础用法

默认配置下即可接入，先保证功能和风格快速落地。

2) 语义定制：自定义图标

通过图标替换对齐业务语义，又不破坏整体 HDS 视觉语气。

3) 视觉密度：自定义尺寸

可以按页面布局密度调整按钮尺寸和留白，兼顾可读性与层次感。

4) 可扩展：自定义内容槽位

通过 @BuilderParam 尾随闭包覆盖默认内容，支持更个性化的表达方式。

第三步：组件发布到 ohpm，降低复用门槛

当能力稳定后，发布为 hds_button，让接入成本从“二次实现”变成“安装 + 配置”。
安装方式如下：

ohpm install hds_button

这种发布方式的价值是：统一体验可以被复用，团队间也更容易保持设计一致。

踩坑/总结

这次实践里，我最重视的不是“功能堆叠”，而是“边界清晰 + 体验统一”。

1. 技术边界必须讲清楚
   材质能力依赖 HdsTabs 悬浮态，不能对外表述成“任意场景都可直接复用的材质按钮”。

2. 统一不等于单一
   HDS 统一的是设计语言，不是禁止定制。尺寸、图标、内容都可定制，但视觉语气要一致。

3. 组件化的真正收益在传播
   从项目内复用走向 ohpm 公开发布，才真正让这套实践产生更大价值和曝光。

结尾：互动

如果你也在做 HarmonyOS 组件封装，欢迎一起讨论：

• 你在项目里是如何平衡“统一风格”和“业务定制”的？
• 对沉浸光感材质这类能力，你更倾向场景封装还是通用抽象？
• 对 hds_button 还有什么点值得优化封装的地方？