HarmonyKit | 鸿蒙新特性应用：10 个开发工具的选型与分类
选型不是拍脑袋
HarmonyKit 目前包含 10 个工具。从最初 5 个 MVP 工具到后来扩展到 10 个，每一个工具的增加都经过了三个维度的评估：使用频率、实现复杂度和独立价值。
这篇文章详细拆解了 10 个工具的选型逻辑、四分类体系的设计原则，以及在两次迭代中验证过的"工具-架构协同"方法论。
项目仓库：https://atomgit.com/VON-/harmony-kit
三维评估模型
维度一：使用频率
开发者日常工作中，有些操作几乎每天都会遇到。HarmonyKit 的工具入选标准是"每周至少一次"。我统计了自己一个月的开发者日常：
- JSON 格式化/校验：每周 15-20 次（查看 API 响应、调试配置文件、检查 build 输出）
- 时间戳转换：每周 5-8 次（排查日志中的时间、API 参数中的时间戳）
- Base64 编解码：每周 3-5 次（解 JWT payload、编码凭证信息）
- URL 编解码：每周 2-3 次（构造 API 请求参数）
- 哈希计算：每周 1-2 次（校验文件完整性、生成 token 指纹）
这些操作在桌面端通过浏览器或终端完成------打开 Chrome DevTools 的 Console，跑一行 JSON.stringify(JSON.parse(str), null, 2)。但在移动端呢？你需要打开一个网站，忍受广告和加载。HarmonyKit 的价值就是把"一行代码能搞定"的操作搬到手机上，让它在 3 秒内完成。
维度二：实现复杂度
每个工具的核心逻辑必须控制在合理范围内。HarmonyKit 的衡量标准是：核心算法代码不超过 100 行，总页面代码不超过 200 行。
超过这个标准的有两个候选被放到了 2.0 版本：
- 二维码生成 ：需要 Canvas 绘制或引入 QR 编码库。
QRCodeGenerator的核心算法有上千行。不满足"100 行核心逻辑"的约束。 - JWT 调试器：需要解析 JWT 结构、验证签名、处理多种算法。复杂度分散在多个子功能中，不是一个"单一工具"。
符合标准的工具反而是那些"看起来简单但每天用"的：
- 进制转换 ：
parseInt(input, fromRadix).toString(toRadix)------核心就一行 - UUID 生成器：一个模板字符串 + 随机数生成------20 行
- 文本统计 ：
length、split、正则计数------20 行
简单的算法不代表没价值。恰恰相反，最简单的工具往往使用频率最高。
维度三：独立价值
每个工具必须能独立使用，不依赖其他工具的输出。如果一个工具的典型使用场景是"先在这个工具里处理，再跳到那个工具里继续"，那这两个工具可能应该合并。
HarmonyKit 所有 10 个工具都满足"单次使用闭环"------用户在工具页内完成输入→操作→复制，不需要跨页面跳转。
四分类体系的设计
格式化分类
成员： JSON 格式化
这个分类目前只有一个工具，但它是整个应用的入口级工具。JSON 格式化有三个子功能：格式化（美化缩进）、压缩（去除空白）、校验（错误定位）。
为什么格式化只有一个工具？因为格式化类操作本质上是一个"有损→无损"的转换过程。JSON 格式化是其中最典型的代表。XML 格式化、YAML 格式化属于低频需求，不在首版范围。
编解码分类
成员： Base64 编解码、URL 编解码
编解码类工具的共同特征是双向操作------编码和解码是成对出现的。UI 设计上，编码和解码放在同一个页面的两个按钮中，而不是分拆为两个独立页面。
Base64 和 URL 是编码领域的"双子星"。它们解决的问题相似但场景互补：Base64 用于二进制→文本的转换，URL 编码用于保留字符的转义。两个工具放在同一个分类下，用户心智模型一致。
计算分类
成员： 时间戳转换、哈希计算、UUID 生成器、颜色转换、进制转换
计算分类是最大的分类，有五个工具。它们的共同特征是单向或双向计算------输入参数，输出结果。计算过程不需要用户理解底层算法。
时间戳和进制转换是"翻译"型计算------将一个表达形式翻译为另一个。哈希和 UUID 是"生成"型计算------根据输入（或随机数）生成一个确定的输出。颜色转换是"互转"型计算------三个色彩空间之间的任意转换。
五个工具共享同一个页面模板：输入控件 + 参数选项 + 计算按钮 + 结果展示 + 复制按钮。差异性体现在参数选项的复杂度------哈希需要选择算法，进制需要选择源进制，颜色需要选择转换方向。
文本分类
成员： 正则测试器、文本统计
文本分类的两个工具处理的是"非结构化文本"------用户的输入不是格式化的数据，而是任意文本。正则测试器的输出是匹配项列表，文本统计的输出是数字指标。
这个分类的特点是实时反馈。正则测试器需要用户反复调整表达式和测试文本，文本统计需要随着输入实时更新计数。因此这两个工具的 UI 设计上，操作按钮和输入区域紧密耦合，反馈延迟几乎是即时的。
从 5 到 10 的迭代经验
首版 5 个工具（JSON、Base64、时间戳、URL、哈希）覆盖了"格式化"和"编解码"两个分类。这个选择是刻意的------先验证两个分类的页面模板是否可以复用，然后再扩展到其他分类。
结果证明模板设计足够通用。第二批 5 个工具（正则、UUID、颜色、进制、文本统计）加入时，不需要修改任何现有工具页的代码，也不需要修改 ToolCard 或 CopyButton 组件。只是在 TOOL_LIST 数组中追加了 5 个对象，然后创建了 5 个页面文件。
这种"零破坏性扩展"是三层架构的核心价值。如果第一批工具和第二批工具在代码上有耦合（比如共享了某个带状态的 service 类），那么新增工具可能影响现有功能。但 HarmonyKit 的 utils 都是无状态的静态方法，每个工具页是独立的功能单元。
没有入选的工具
除了前面提到的二维码和 JWT，还有几个候选被评估后被搁置：
图片 Base64 编码 。将图片文件编码为 Base64 Data URL 是一个常见需求。但实现需要访问文件系统（@kit.CoreFileKit）和图片解码（@kit.ImageKit），引入了两个额外的系统 Kit。而且不同格式的图片（PNG、JPEG、WebP）编码逻辑各异。首版暂不纳入。
Unicode 码点转换 。Unicode 字符和码点之间的互转（比如 U+4E2D ↔ 中）。核心逻辑简单（String.fromCharCode + charCodeAt），但使用频率太低。可能作为未来"字符工具"分类的一个子功能。
Markdown 预览。Markdown 转 HTML 需要完整的 Markdown 解析器。即使使用最简化的正则替换方案，代码量也在 300 行以上。而且预览效果需要 WebView 渲染，引入了新的组件类型。暂不纳入。
分类的未来演进
随着工具数量增长，四个分类会逐渐变得不平衡。"计算"分类已经有 5 个工具，而"格式化"只有 1 个。未来可能会拆分"计算"为"转换计算"和"生成计算"两个子类，或者新增"图形"、"网络"等新分类。
但分类体系的调整不能影响现有的 Tab 导航。CATEGORIES 数组定义在 model 层，Index.ets 通过 ForEach(CATEGORIES, ...) 动态生成 Tab。这意味着增加或重命名分类只需要修改 model 中的一行数组，不需要改任何 UI 代码。
这种"数据驱动 UI"的设计在 ArkUI 中特别自然------ForEach 的声明式语法配合响应式状态管理，让你感觉不到"数据和 UI 的同步"是一个需要解决的问题。