莱夢做了 ToolMaster 这款纯离线的 HarmonyOS NEXT 开发者工具箱之后，很多朋友问我最多的一句话是：“现在 App 不联网还能算工具吗？”我的回答很直接：开发者工具恰恰不应该联网。我在鸿蒙原生应用上用 ArkTS 从零搭了一个免权限、零上传、所有内容都在本机完成的工具箱，把 JSON 格式化、Base64 编解码、时间戳转换、哈希计算、正则测试、URL 编解码这些高频功能全部收进 App 里，不申请任何网络权限，不做埋点，不弹广告，打开就能用。整个项目从设计到上架遇到的坑，这篇博文一次讲透。
1. 项目定位：为什么要在 HarmonyOS NEXT 上做一个纯离线工具箱
1.1 从“什么都联网”到“什么都本地”
做工具箱之前，我先列了一张“烦人清单”，把日常开发中需要反复打开网页、切换聊天窗口、找在线工具站的场景全部写了下来：JSON 想格式化但日志太长、接口返回的 Base64 图片想临时解出来看一眼、时间戳要转日期却发现忘了打开网页、给文件算个 MD5 还得装一个巨大的桌面软件。
这些场景有两个共同点：第一，每次操作的数据量都不大，但发生频率极高；第二，数据很可能涉及接口报文、密钥、调试参数，属于不该出现在公网上的内容。过去用网页工具图方便，但你把一段内部接口的 JSON 塞进一个免费网站时，等于默许它存到对方服务器上。对于企业开发者，这甚至可能触发信息安全问题。
HarmonyOS NEXT 这个平台恰好适合做这件事。它的 ArkTS 语言和 ArkUI 声明式框架虽然和 Android、iOS 都不一样，但系统自带的 util 工具库、加密框架、持久化能力已经足够覆盖一个工具箱 90% 的需求。加上 NEXT 的权限审核很严格，纯离线应用不申请任何权限，上架时省心，用户使用时也放心。
1.2 工具清单的选型标准
工具不是越多越好，维护一个臃肿的“全家桶”反而会拖垮体验。我的选型标准有三条：第一，必须能纯本地完成，不依赖云端计算；第二，操作链路要短，最好从进入到拿到结果不超过两次点击；第三，有明确的高频使用场景，而不是为了凑数量。
按这套标准，第一版 ToolMaster 落地了六类工具：JSON 格式化、Base64 编解码、时间戳转换、哈希计算（MD5/SHA-1/SHA-256）、正则表达式测试、URL 编解码。后来又加了一个收藏夹机制，用户可以把常用的工具固定在首页头部。
有人建议我加“二维码生成”“颜色选择器”“ASCII 码表”这类功能，我评估后的结论是：二维码生成放到第二版，因为它引入的绘制逻辑会显著增加包体，而且扫码场景在调试中占比并不高。工具类 App 宁可少而精，也不要让用户在一堆低频功能里找不到真正需要的入口。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体架构与工程搭建
2.1 项目结构与模块划分
先用 DevEco Studio 创建一个空应用（Empty Ability），选择 Stage 模型。Stage 模型是 HarmonyOS NEXT 的主流形态，它的 isolation 机制天然适合工具类应用——每个 UIAbility 独立运行，不会互相干扰。
工程结构我按“功能聚合”而不是“文件类型”来组织。六个工具各自放在一个独立的工具类文件里，UI 层只负责调用，不写业务逻辑。当前版本的目录大概是这样的：
code复制entry/src/main/
├── ets/
│ ├── entryability/
│ │ └── EntryAbility.ets
│ ├── pages/
│ │ ├── Index.ets // 工具网格首页
│ │ ├── JsonToolPage.ets
│ │ ├── Base64ToolPage.ets
│ │ ├── TimestampToolPage.ets
│ │ ├── HashToolPage.ets
│ │ ├── RegexToolPage.ets
│ │ └── UrlToolPage.ets
│ └── common/
│ ├── json_util.ets // JSON 格式化核心逻辑
│ ├── base64_util.ets // Base64 编解码
│ ├── hash_util.ets // 哈希计算
│ ├── storage_util.ets // Preferences 封装
│ └── types.ets // 全局类型定义
├── resources/
│ ├── base/element/color.json
│ ├── base/element/string.json
│ └── base/media/
└── module.json5
这里有个设计上的取舍：为什么每个工具都单独拆一个 Page 而不是做成单个页面内切换 Tab？因为工具类 App 的状态管理讲究简单直接，每个工具页的输入框、结果区、历史记录都是独立的，如果在一个页面里用 Tabs 包裹六个工具，状态回收和页面缓存都会变复杂。拆成独立页面后，配合 Navigation 的路由跳转，每个页面只管自己的事情，代码可维护性高很多。
在 types.ets 里我定义了所有工具页面共用的数据结构，比如历史记录统一用一个 HistoryItem：
typescript复制export interface HistoryItem {
toolId: string;
input: string;
output: string;
timestamp: number;
}
这个类型定义后来帮了大忙。ArkTS 对对象结构要求非常严格，如果没有先定义 interface，在写 Preferences 存取时编译器会反复报错。提前把公共类型沉淀出来，能省掉很多全局搜索替换的麻烦。
2.2 ArkTS 下的“类型约束”带来了哪些坑
如果说这次开发里最需要适应的是什么，一定是 ArkTS 对 JavaScript 动态特性的限制。它不是 TypeScript 的简化版，而是带严格运行约束的静态类型语言。任何对象字面量都必须有明确的 interface 或 class 定义，不能用 any，也不能在运行时动态添加属性。
刚开始我习惯性写了一个万能解析函数：
typescript复制function parse(input: string): any {
return JSON.parse(input);
}
编译直接报错： ArkTS 不支持 any 类型。改法也很简单，把返回值定义成一个已知结构，或者在 JSON.parse 之后立刻交给一个类型确定的方法去处理：
typescript复制function parseJson(input: string): object | null {
try {
return JSON.parse(input) as object;
} catch (e) {
return null;
}
}
这类约束初看是麻烦，但实际写下来会发现，它对工具类 App 反而是一种保护。六个工具页面都要接收用户输入，输入内容千奇百怪，严格类型约束让我在编译期就堵住了很多解析异常，而不是等到用户运行时崩溃。
2.3 离线能力的根基：不申请任何网络权限
纯离线不只是一个噱头，它意味着我要主动检查 module.json5 里是否有任何网络相关权限。
HarmonyOS NEXT 的权限声明在模块的 module.json5 文件中。默认的空应用模板不会申请网络权限，这是正确的起始状态。很多开发者后来不小心引入一个 SDK，SDK 自动往配置文件里注入 ohos.permission.INTERNET，于是 App 就莫名其妙变成了“联网应用”。我做一个纯离线工具，最核心的一条纪律就是：任何第三方依赖都先检查它在配置里加了什么，不在线下载图片、不检查版本更新、不拼装 URL，从源头掐断联网可能。
实际测试时，我开飞行模式把六个工具全部跑了一遍，所有功能正常。这种“断网可用”的体验放在开发者工具这个类别里，本身就是价值——你在地铁里调接口、在客户现场处理数据、在飞行模式下研究日志，工具依然能用。
3. 六大核心工具的实现思路与细节
3.1 JSON 格式化：校验、解析、错误定位一条龙
JSON 格式化是开发者工具箱里的“流量之王”，但它的门槛比看起来高很多。简单版只需要 JSON.stringify(JSON.parse(input), null, 2)，但实际使用中，用户贴进来的经常是截断的报文、带 BOM 头的日志、混着中文引号的错误内容。如果只做一次 parse，报错信息对用户毫无帮助。
我在 json_util.ets 里设计了三个步骤：
- 先做语法校验，如果解析失败，捕获异常并返回错误位置；
- 解析成功后，对结果按缩进 2 个空格格式化；
- 额外提供“压缩”模式，把格式化后的内容压回单行，适合重新拼接请求体。
错误定位这块是体验重点。ArkTS 的 JSON.parse 抛出的异常信息不够友好，我做了二次处理：正则匹配错误信息里的数字，定位到出错行和列，然后从原始输入中把那一行截取出来单独展示。这样用户能立刻看出是第几行多了逗号还是少了括号。
这里有一个很关键的性能细节：如果输入的是超大 JSON（比如几百 KB 的接口响应），JSON.stringify 缩进 2 个空格会让字符串膨胀几十倍。我在格式化前先判断长度，超过 500KB 就默认缩进 2 个空格但关闭自动展开全部层级，等用户点击“展开”再全量渲染。实测下，这个阈值能把界面卡顿控制在 300ms 以内。
“格式化”按钮的背后逻辑，其实经历了三代写法。第一版直接在主线程同步跑；第二版用 Promise 异步但解析逻辑没隔离，只是换个线程池；第三版老老实实用 @ohos.taskpool 把 parse 和 stringify 都放到任务池里执行，再通过 Promise 把结果传回 UI 线程。在 DevEco Studio 的 profiler 里对比，第三版对超大 JSON 的响应提升了近一倍，而且不再阻塞页面滑动。
typescript复制@Concurrent
function formatJsonConcurrent(input: string): string {
const obj = JSON.parse(input);
return JSON.stringify(obj, null, 2);
}
async function safeFormatJson(input: string): Promise<string> {
try {
return await taskpool.execute(formatJsonConcurrent, input) as string;
} catch (e) {
return Promise.reject(e);
}
}
3.2 Base64 编解码：别小看这个最常用的功能
Base64 看起来是最简单的一个工具，但实现时踩了几个“想当然”的坑。HarmonyOS NEXT 的系统库提供了 util.Base64Helper，可以直接完成编码和解码。它接收的是 Uint8Array，不是字符串，所以字符串和字节数组之间的转换必须自己做。
编码方向：文本输入先转成 UTF-8 字节，再交给 Base64Helper。解码方向：Base64 字符串先 decode 成字节，再按 UTF-8 还原成文本。关键点在于，开发者的“Base64”未必都是文本。很多人会把图片的 Base64 丢进来想要还原成图片，第一版我不支持；后来加了“输出为文件”的功能，用 @ohos.file.fs 写文件，但为了不增加权限，只允许用户保存到 App 的沙箱目录，再通过系统分享能力导出。
Base64 的另一个坑是字符集。HarmonyOS 的 TextEncoder 默认是 UTF-8，如果用户粘贴的是 GBK 编码的内容，转出来就会有乱码。我在 UI 上加了一个“字符集选择”，提供 UTF-8 和 GBK 两个选项，默认 UTF-8。GBK 的支持需要引入额外的编解码库，我评估后决定用系统能力 + 简单映射处理核心场景，够用。
解码失败的处理也很重要。Base64 字符串里混入换行符或空格很常见，我做了过滤：解码前先剔除所有空白字符。但也要设置一个阈值：过滤后如果长度不是 4 的倍数，则直接提示“输入不是合法的 Base64”，而不是静默拼接。
3.3 时间戳转换：时区与精度才是真正的考验
时间戳工具是所有工具里“看起来最简单、做起来最阴间”的一个。核心就一个公式：new Date(timestamp)，但真实使用场景比这复杂得多。
第一，精度问题。开发者手里的时间戳可能是秒（10 位）也可能是毫秒（13 位），很多人在线转换时没注意，转出来发现差了整整 1000 倍。我提供了一个自动识别逻辑：如果数值小于 100 亿，自动按秒处理并在界面上标明“已识别为秒级”；大于等于 100 亿按毫秒处理。用户也可以手动切换精度，避免误判。
第二，时区问题。HarmonyOS NEXT 的 Date 转字符串默认走系统时区。但调试服务端日志时，接口返回的时间戳经常是 UTC 的，需要看 UTC 时间而不是本地时间。我在结果区同时展示三行：本地时间、UTC 时间、ISO 8601 格式。这样无论用户拿日志和哪个时区的服务端比对，都能直接对得上。
第三，反向转换。很多工具只做时间戳转日期，但开发者常常需要“2024-12-18 14:30:00 转成时间戳”。这个功能我做了“按当前时区计算”，并在结果里同时给出秒和毫秒两种值。这里有一个边界：如果用户输入的日期格式不规范，比如用中文“2024年12月18日”，统一先做格式正则替换，全部转成 YYYY-MM-DD HH:mm:ss 再交给 Date.parse。
3.4 哈希计算：离线场景下的安全辅助
哈希功能我用的是 @ohos.cryptoFramework。这个库的抽象程度比较高，你需要先通过工厂方法创建一个摘要实例，然后 update 数据，最后 digest 拿结果。整个过程是异步的，要在 Promise 里等结果。
支持三种算法：MD5、SHA-1、SHA-256。MD5 和 SHA-1 现在只适合做完整性校验，不建议用于安全场景，我在 UI 上花了一行字说明，避免有用户误用。
这里有个必须处理的细节：digest 返回的是 Uint8Array，要转成十六进制字符串才能方便阅读。转换不能直接用 toString(16)，因为数组里每个元素是一个 0-255 的数值，需要逐字节补零拼字符串：
typescript复制function bytesToHex(bytes: Uint8Array): string {
let result = '';
for (let i = 0; i < bytes.length; i++) {
const hex = bytes[i].toString(16).padStart(2, '0');
result += hex;
}
return result.toLowerCase();
}
另一个必须养成的习惯是：摘要对象用完后必须调用 md.release() 释放底层资源。cryptoFramework 底层是 C++ 实现的，实例不释放会导致内存持续上涨。我一开始漏了这一步，用 profiler 抓内存时发现连续计算几十次后内存曲线不回落，排查半天才找到是摘要对象没有释放。
为了让这个工具更实用，哈希功能支持两个输入源：文本输入和文件选择。文件选择用系统提供的 DocumentViewPicker，选完以后通过 @ohos.file.fs 打开文件流，分块读取并逐块 update 到摘要对象。分块读取是必要的，一次性读一个大文件进内存会让 App 直接被系统杀掉。
3.5 正则测试与 URL 编解码：小而美的细节打磨
正则测试的难度不在正则引擎，而在于输入框的转义处理。用户在文本框里输入 \d+，如果直接塞给 new RegExp(input)，反斜杠会被字符串解析吃掉一层，导致正则失效。解决办法是让用户输入时不做任何转义，原样传入，由 RegExp 构造函数统一处理。这里我把输入框的 enableAutoFill 关了，避免系统输入法自动纠正干扰。
测试时，正则的匹配结果我用高亮文本展示，在 ArkUI 里用 Text 组件的 span 一段一段拼接。这个功能的代码不复杂，但表达式性能对 UI 的影响很大。我用了一个技巧：只展示前 50 个匹配结果，避免用户用一个灾难性回溯的正则把 UI 线程卡死。界面上也加了“超时提示”，当匹配耗时超过 3 秒，直接终止并建议用户优化正则。
URL 编解码是最轻量的一个工具，用 encodeURIComponent 和 decodeURIComponent 各封装一层即可。但有一个注意点：ArkTS 里如果直接使用 decodeURIComponent 解析一个格式错误的 URL 编码字符串（比如包含没有 % 前缀的非法序列），会抛出 URIError。我做了异常捕获，并提示用户“检查是否混入了非 URL 编码字符”。
4. 数据持久化：历史记录与收藏夹的离线存储方案
4.1 Preferences 的正确打开方式
HarmonyOS NEXT 提供的数据持久化方案里，Preferences 最适合轻量键值存储。它不是一个数据库，而是基于 XML 或类似机制的小型存储，适合存设置项、历史列表这类体量较小的数据。
我在 storage_util.ets 里封装了统一的读写方法。写的操作要注意：putSync 只是把数据放到缓存，必须调用 flush() 才会真正落盘。flush 是异步方法，很多开发者忘了 await 它，导致 App 被系统杀死后数据丢失。我的统一封装里把 flush 也包进去了，所有调用方只要 await saveHistory() 就行。
Preferences 能存的数据类型有限，复杂结构要先转成 JSON 字符串再存。读的时候再解析回来。历史记录我用一个数组存，上限 50 条，超过后从最旧的开始删除。这里的删除策略是“插入前判断”，保证每次写入后数组都不会超长。
一个有价值的细节：Preferences 在每次修改时其实是全量写入的。如果历史记录一直增长，性能会越来越差。50 条限制正是基于这个考虑，实测在普通设备上，50 条 JSON 字符串的写入耗时在毫秒级，完全无感知。
4.2 收藏夹的懒加载与去重策略
收藏夹的存储方式类似，只是多了一个“去重”逻辑。用户可能反复收藏同一个工具，我用工具的唯一 ID 作为 key，收藏状态存一个 boolean。首页加载时，先读取收藏夹数组，再根据 ID 去过滤工具列表，把收藏的工具排到最前面。
为了不拖慢首页渲染速度，收藏夹的加载采用懒加载策略：首页先渲染全部工具的静态网格，等 onPageShow 触发后再异步读取收藏状态，最后通过 @State 数组动态更新排序。这样用户打开 App 的第一帧不会因为读取 Preferences 而白屏。
这里有一个 UI 排序的经验：动态重排数组会让 ForEach 里的 item 组件被重建，如果用户正在滑动列表，可能会感到卡片轻微跳动。我采用的优化是给每个 GridItem 加一个稳定的 key，并优先重渲染而不是整体重建。ArkUI 的 diff 机制对这种“局部排序变化”的响应比整体重绘要平滑得多。
5. UI 设计中的体验细节
5.1 网格布局如何做到“疏而不散”
首页采用 Grid + GridItem 的网格布局，两列排布。每个工具卡片包含图标、名称、一句话描述。我没有把图标做得很花哨，而是用系统图标 + 品牌色的组合，保证包体不膨胀。
网格布局的自适应是一个需要花心思的地方。不同手机屏幕宽度差异很大，折叠屏的宽屏模式更是考验布局。我用 Grid 的 columnsTemplate 属性动态计算列数：根据屏幕宽度判断是两列还是三列。宽屏设备的列数太少会让卡片变得异常宽大，视觉上很空洞；列数太多又会显得拥挤。实测在普通手机两列、折叠屏展开三列是最舒服的比例。
卡片点击跳转用 Navigation 组件，配合 NavPathStack 管理页面栈。这里我踩过一个坑：如果直接在 GridItem 的 onClick 里 push 页面，连续快速点击会重复入栈。解决办法是加一个点击锁，上一次跳转动画没结束前忽略新的点击。
5.2 深色模式适配
开发者群体使用深色模式的意愿极高，工具箱不做深色模式等于自断一臂。HarmonyOS NEXT 的深色适配通过资源限定词实现：在 resources 目录下建 dark 限定词目录，放一套深色资源，系统切换时会自动加载对应资源。
但纯资源限定词只能处理颜色切换，处理不了“深浅模式下图标要有不同的底色”这类需求。我采用的做法是：卡片背景色用资源文件定义，文字颜色也用资源文件定义，但卡片上的默认图标统一用品牌色，不随模式变化，这样深浅模式下的视觉一致性就保住了。
一个容易踩的坑：如果不小心在代码里硬编码了颜色字符串（比如 Color.White 或 '#FFFFFF'），深色模式下这些区域会保持刺眼的白色。我最后走查时用了一个笨办法：全局搜索 Color. 和 # 开头的内容，把凡是写死在代码里的颜色全部替换成资源引用。这个操作虽然繁琐，但一次替换能避免后续大量 bug。
5.3 输入框、复制反馈等小交互
工具类 App 的输入体验直接决定用户去留。六个工具的输入框都统一了“清空”按钮，在输入内容不为空时显示在输入框右侧。用 @State 绑定输入字符串，通过 onChange 实时驱动清空按钮的显隐。
复制功能是工具箱里的高频操作。格式化的 JSON、计算出的哈希、转换后的时间戳，用户都要复制到剪贴板用。HarmonyOS NEXT 的剪贴板接口是 @ohos.pasteboard。这个 API 本身不复杂，但有一个体验细节：调用成功后通过 promptAction.showToast 提示“已复制”，能让用户明确感知操作成功。
我还加了一个“粘贴”示例按钮。每次进入工具页时，自动从剪贴板读取最近内容填充到输入框示例区。这个功能要谨慎处理——如果剪贴板内容不是当前工具期望的格式，用户会觉得被冒犯。我的策略是只放一个可点击的“粘贴剪贴板”按钮，由用户主动触发，不在页面上自动读取。
6. 常见问题与排查实录
6.1 JSON.parse 在 ArkTS 里的异常处理
之前提过 ArkTS 对 JSON.parse 的返回类型有严格约束。这里再补充一个真实案例：我在格式化工具里用 JSON.parse 解析一个空字符串，运行时直接抛异常。原因是 JSON.parse('') 本身就是非法的，它不会返回 null，而是直接 throw。解决方法是先判断输入是否有效，再做解析。
这个问题在 TypeScript 里可能被忽略，因为类型系统允许你把它当作任何类型。但 ArkTS 的运行时约束更严格，类型不对就会在运行时报错。建议所有做鸿蒙应用的朋友，在封装工具函数时统一：
typescript复制function tryParseJson(input: string): object | null {
if (!input || input.trim().length === 0) {
return null;
}
try {
return JSON.parse(input) as object;
} catch (e) {
return null;
}
}
6.2 正则表达式的转义问题
很多用户在正则工具里输入 \w+，点“测试”发现没有匹配结果。排查半天，发现是字符串层级的转义：输入框的 onChange 拿到文本时，反斜杠还在，但传给 new RegExp() 时，如果经过了中间变量、JSON 序列化等环节，反斜杠可能被某层处理吃掉。
我的解决方案是：在 RegexToolPage 里直接从 @State input: string 拿值，不经过任何额外转换，直接 new RegExp。这个“少做一步”的思路在工具类开发里很有用——中间环节越少，问题越少。
还有一个正则测试特有的坑：连续点击“测试”按钮，如果正则带了全局标志 /g，匹配结果是带 state 的。同一个 RegExp 对象第二次执行 exec 时，会从上次结束位置开始。在页面里每次点击测试时都重新 new RegExp()，不要复用上一次的对象，就能避开这个隐蔽问题。
6.3 时区偏移导致的时间转换错误
时间戳转换功能上线后，有用户反馈：输入 1700000000，系统转出来的本地时间和在线工具对不上，差了整整 8 小时。排查后发现是他的手机系统时区设置成了 UTC，而在线工具默认按中国时区展示。这个案例让我意识到，时区问题不能靠“系统自动”解决，必须在 UI 上明确显示当前使用的时区。
后面我用 Intl.DateTimeFormat 拿到当前设备的时区 ID，在结果区直接展示“设备时区：Asia/Shanghai（UTC+8）”这样一行文字，用户一眼就能知道结果是按什么时区计算的。同时提供“按 UTC 显示”的切换按钮，这两行小改动治好了 90% 的时区相关反馈。
6.4 哈希计算的对象释放问题
哈希工具的崩溃排查是这次开发里花时间最多的一件事。现象是：连续计算大文件哈希十几次后，App 崩溃，但没有明确错误堆栈。抓取内存镜像后确认是循环创建的摘要对象没有释放，底层 Native 资源耗尽。
修复方案很简单，在 finally 块里确保释放：
typescript复制let md = cryptoFramework.createMd('SHA256');
try {
await md.update({ data: chunk });
const result = await md.digest();
return result;
} finally {
md.release();
}
给所有用到原生资源的对象都套上 try-finally，不是可选项，是必须项。这个习惯如果一开始就有，后面排查工作能省一大半。
6.5 深色模式资源不生效
深色模式适配完成后，我发现一个问题：部分页面切到深色模式后，输入框背景还是白色的。排查后发现，那些输入框用的是系统默认样式，而默认样式在深浅色下的表现不完全跟随资源限定词。
解决方法是给输入框显式绑定背景色资源。但这也会带来新问题：如果直接绑定 resource，用户切到深色模式时，输入框背景色资源是变化了，但 border 颜色还是旧的，看起来像没适配好。我把输入框的 borderColor 也改成资源引用，终于实现了完整的深色模式切换。
6.6 参数传递里的“undefined”陷阱
ArkTS 的严格模式下，undefined 处理非常容易出问题。我在做 URL 解码工具时遇到一个 crash：明明输入框里没有内容，用户点击解码按钮后，后台抛出一个 null pointer 异常。仔细查了才发现，decodeURIComponent('') 在部分版本上会返回空字符串，但我的代码里在调用后直接取了 length，空字符串本身没问题，问题出在输入框的初始值可能不是 '' 而是 undefined。
此后我定了一个规矩：所有输入框的 @State 绑定字段，初始化必须显式赋 ''，不能在页面 onPageShow 里依赖“系统默认值”。这个习惯让后来的代码少了非常多原本需要兜底的边界判断。
7. 版本迭代与后续规划
ToolMaster 第一版做完后，我给自己列了一个“不能急着做”清单。有些功能呼声很高，但我觉得当前版本不合适，比如二维码扫码、网络抓包、颜色拾取。它们要么需要新权限，要么需要引入较重的第三方库，会破坏纯离线的简洁性。
我个人在实际操作中的体会是：工具类 App 最大的门槛不是技术，而是“克制”。不加权限、不加广告、不采集数据，这些“不做”的设计决策，才是用户真正信任你的原因。后续我会继续在现有框架上加一些纯本地、低依赖的功能，比如多种进制转换、Unicode 编码查询、正则表达式常用语法速查表，以及把历史记录增加搜索能力。如果你也在做 HarmonyOS NEXT 的实战项目，希望这篇内容能帮你少踩几个坑。