HarmonyOS鸿蒙PC平台nodejs三方库移植实战（bcrypt和 sqlite3移植笔记）

原创 已于 2026-07-16 17:42:04 修改 · 403 阅读 · 5 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
收录于
鸿蒙PC

当前文章被收录于：

鸿蒙PC
79 篇文章 6 人学习
订阅专栏 查看详情
于 2026-07-15 22:41:44 首次发布

本文记录下移植nodejs三方库bcrypt和 sqlite3到鸿蒙PC上的踩坑过程和经验分享。鸿蒙PC平台nodejs三方库移植也很简单。鸿蒙 PC 安装 bcrypt 和sqlite3三方库实录：预编译与源码编译双路实战，关于 HarmonyOS + Node.js 原生模块的兼容性测试验证总结笔记。

更多交流学习，欢迎加入开源鸿蒙PC社区：https://harmonypc.csdn.net/

欢迎在PC社区平台申请新建项目：https://atomgit.com/OpenHarmonyPCDeveloper

猫哥的博客：https://blog.csdn.net/qq8864

背景

在鸿蒙 PC 上，（安装好node环境的前提下）执行了这样一个简单的命令：

npm install bcrypt

然后——没有任何报错。node-gyp 没有崩毁，编译器没有报缺头文件，3 个包安静地装好，测试用例全部通过。

这在 Node.js 原生模块的安装史上，算得上一个"小反常"。

不过后面我们进一步验证了：不仅预编译能装，强制走源码编译也完全 OK。鸿蒙 PC 上的 C++ 工具链（来自 Harmonybrew 的 clang、make、python3）完整可用。

注： 踩坑记，从应用市场上下载安装的node-H软件包，版本23.x有问题啊，直接崩掉，建议卸载掉它。推荐使用 Harmonybrew 的软件包工具安装node环境。

安装成功真机截图：
在这里插入图片描述

bcrypt 是什么？

bcrypt 是一个密码哈希库，以 C++ 编写，通过 Node-API 暴露给 JavaScript。它的安装有两种路径：

路径 A（预编译）：
bcrypt 官方发布的 .node 二进制
     → node-gyp-build（安装时脚本）
复制到 node_modules 中

路径 B（源码编译）：
bcrypt 源码 (.cc/.h)
     → node-gyp 调用 C++ 编译器
生成 .node 二进制

路径 A 静默无感，路径 B 则依赖完整的 C/C++ 编译工具链。绝大多数安装报错都发生在路径 B。

常规安装常见的坑

如果走源码编译路径，鸿蒙系统并不默认提供 GNU/Unix 开发工具链，典型的报错有：

错误信息根因
gyp ERR! stack Error: not found: make缺 GNU Make
fatal error: 'node.h' file not foundNode 头文件未安装
fatal error: 'openssl/opensslv.h' file not foundOpenSSL 开发头文件缺失
gyp ERR! stack Error: Could not find any Python installationPython 未安装（node-gyp 依赖）
clang: error: no such file or directory编译器路径未配置

环境准备：在鸿蒙 PC 上搭建 C++ 编译工具链

在尝试安装原生模块之前，需要先确保鸿蒙 PC 具备基本的 C/C++ 编译环境。这块依赖 Harmonybrew（专为 OpenHarmony 移植的 Homebrew 发行版）来完成。

⛔️ HMDFS 文件系统缺陷
HiShell 环境中 TMPDIR 默认指向 /storage/Users/currentUser，该目录承载在 HMDFS 上。HMDFS 存在已知文件系统缺陷，可能导致 node-gyp 编译过程中临时文件写入失败。

建议在安装工具链后，先设置环境变量将临时目录和工作目录指向非 HMDFS 路径：

export TMPDIR=/data/storage/el2/base/files/tmp
mkdir -p $TMPDIR

详见 featured-packages.md 场景一 中的完整说明。

安装 Harmonybrew

步骤操作
① 卸载冲突软件如果安装了 GitNext 和 DevBox，先卸载
② 打开安全开关设置 → 系统 → 开发者选项 → 打开"开发者选项"；设置 → 隐私和安全 → 高级 → 打开"运行来自非应用市场的扩展程序"
③ 开启隐藏开发者菜单设置 → 关于本机 → 连续点击"软件版本"7 次 → 确认重启
④ 安装 Harmonybrewzsh -c "$(curl -fsSL https://harmonybrew.atomgit.com/install.sh)"
⑤ 配置环境变量echo 'eval "$(/storage/Users/currentUser/.harmonybrew/bin/brew shellenv)"' >> ~/.zshrc 然后执行 eval 使生效

本文收录于 Harmonybrew 特色软件包清单

安装编译所需工具

推荐使用 Harmonybrew 的一站式开发工具包：

# 安装开发工具包（含 ohos-sdk clang、llvm-gcc-compat、make、coreutils 等）
brew install devel-base

# 同时安装 Python（node-gyp 依赖）
brew install python

💡 为什么推荐 devel-base？ 它相当于 Debian 中的 build-essential，级联依赖了 ohos-sdk、llvm-gcc-compat、make、coreutils 等包。其中 ohos-sdk 提供的 clang 链接器经过了封装，编译产物会自动带有代码签名，确保 .node 文件能被 Node.js 运行时正常加载。

如果只需要验证编译链路通不通，安装普通 LLVM 也可以：

brew install llvm make cmake python

但正式项目建议使用 devel-base，避免因代码签名问题导致运行时加载失败。

安装后检查关键工具是否就绪：

clang++ --version   # C++ 编译器
make --version      # GNU Make
python3 --version   # node-gyp 脚本依赖

💡 提示：brew list 可查看已安装的全部包；brew search [keyword] 搜索可用包；brew update 更新包索引。

这套环境就绪后，鸿蒙 PC 就具备了编译绝大多数 node-gyp 原生模块的能力。下面安装 bcrypt 就不再依赖预编译路径——即使用走源码编译，工具链也完整可用。

为什么这次这么顺利？

1. bcrypt@6.0.0 用了预编译策略，且覆盖了鸿蒙的架构

这是最核心的原因。

bcrypt 从 6.x 开始，安装脚本从 node-gyp rebuild（每次都编译）切换为 node-gyp-build（优先下载预编译二进制）。而 bcrypt@6.0.0 的官方预编译包覆盖了以下平台：

prebuilds/
├── darwin-arm64
├── darwin-x64
├── linux-arm
│   ├── bcrypt.glibc.node
│   └── bcrypt.musl.node
├── linux-arm64
│   ├── bcrypt.glibc.node       → glibc 变体
│   └── bcrypt.musl.node         → musl 变体，鸿蒙命中
├── linux-x64
│   ├── bcrypt.glibc.node
│   └── bcrypt.musl.node
├── win32-arm64
├── win32-x64

安装时 node-gyp-build 检测到 linux-arm64 + musl libc，精准匹配了 bcrypt.musl.node，直接复制使用，完全绕过了 C++ 编译环节。

2. --tag-libc 构建参数正确生成了 musl 变体

bcrypt@6.0.0 的 npm 构建脚本是：

prebuildify --napi --tag-libc --strip

--tag-libc 参数让构建 CI 分别为 glibc 和 musl 各生成一个 .node 变体：

linux-arm64/
├── bcrypt.glibc.node      → 链接 glibc，适用 Ubuntu/Debian 等
└── bcrypt.musl.node        → 链接 musl，适用 Alpine/HarmonyOS

鸿蒙 PC 的系统 libc 是 musl，node-gyp-build 自动选择了 bcrypt.musl.node。不依赖任何二进制兼容层，完美匹配。

3. 即使强制走源码编译，Harmonybrew 工具链也完全胜任

我们还做了另一个实验——删除 build/ 目录后强制走源码编译：

rm -rf node_modules/bcrypt/build
npm rebuild bcrypt --foreground-scripts

输出清晰显示：clang++ 被调用编译了 src/blowfish.cc、src/bcrypt.cc 和 src/bcrypt_node.cc，链接生成了 bcrypt_lib.node。测试全部通过。

在这里插入图片描述

这意味着 Harmonybrew 安装的 clang 编译器、GNU Make、Python 3、全链路可用。

依赖状态
clang++（C++ 编译器）✅ 来自 Harmonybrew
make（构建工具）✅ 来自 Harmonybrew
python3（node-gyp 脚本依赖）✅ 来自 Harmonybrew
node.h（Node API 头文件）✅ 随 Node 安装自带

4. 完整的测试用例验证了功能正确性

为了确认编译产物正确可用，我们编写了一组覆盖 bcrypt 核心 API 的测试用例，涵盖：

  • 异步 hash + compare：多个密码串（含中文、空密码）
  • 不同 saltRounds：验证 $2b$ 格式和轮数编码
  • 同步 API：hashSync / compareSync
  • 边界情况：空密码输入
  • getRounds：校验 hash 中编码的 saltRounds 值
const bcrypt = require('bcrypt');

const passwords = ['test123', 'Hello@2024', 'aB3#xyZ!', '密码123', ''];
const saltRounds = [4, 10, 12];

async function runTests() {
  let passed = 0;
  let failed = 0;

  console.log('🧪 bcrypt 测试用例\n' + '='.repeat(40));

  // 测试 1: 基础 hash + compare
  console.log('\n📌 测试 1: hash + compare 基本流程');
  for (const pw of passwords) {
    try {
      const hash = await bcrypt.hash(pw, 10);
      const match = await bcrypt.compare(pw, hash);
      const wrong = await bcrypt.compare('wrong-' + pw, hash);
      const ok = match === true && wrong === false;
      console.log(`   ${ok ? '✅' : '❌'} hash("${pw || '(空)'}") → compare → ${ok ? '正确' : '失败'}`);
      ok ? passed++ : failed++;
    } catch (e) {
      console.log(`   ❌ hash("${pw || '(空)'}") 抛出异常: ${e.message}`);
      failed++;
    }
  }

  // 测试 2: 不同 saltRounds
  console.log('\n📌 测试 2: 不同 saltRounds');
  for (const r of saltRounds) {
    try {
      const hash = await bcrypt.hash('test123', r);
      const parts = hash.split('$');
      const rounds = parts[2];
      const salt = (parts[3] || '').slice(0, 6);
      const ok = rounds === String(r) && parts[1] === '2b';
      console.log(`   ${ok ? '✅' : '❌'} saltRounds=${r} → $${parts[1]}$${rounds}$${salt}...`);
      ok ? passed++ : failed++;
    } catch (e) {
      console.log(`   ❌ saltRounds=${r} 异常: ${e.message}`);
      failed++;
    }
  }

  // 测试 3: 同步 API
  console.log('\n📌 测试 3: 同步 API (hashSync / compareSync)');
  try {
    const hash = bcrypt.hashSync('sync-test', 8);
    const ok = bcrypt.compareSync('sync-test', hash) && !bcrypt.compareSync('wrong', hash);
    console.log(`   ${ok ? '✅' : '❌'} hashSync + compareSync ${ok ? '正常' : '异常'}`);
    ok ? passed++ : failed++;
  } catch (e) {
    console.log(`   ❌ sync API 异常: ${e.message}`);
    failed++;
  }

  // 测试 4: 空值保护
  console.log('\n📌 测试 4: 边界情况');
  try {
    const h1 = bcrypt.hashSync('', 4);
    const ok = bcrypt.compareSync('', h1);
    console.log(`   ${ok ? '✅' : '❌'} 空密码 hash+compare ${ok ? '正常' : '异常'}`);
    ok ? passed++ : failed++;
  } catch (e) {
    console.log(`   ❌ 空密码处理: ${e.message}`);
    failed++;
  }

  // 测试 5: getRounds
  console.log('\n📌 测试 5: getRounds 解析 hash 轮数');
  try {
    const hash = bcrypt.hashSync('rounds-test', 11);
    const rounds = bcrypt.getRounds(hash);
    const ok = rounds === 11;
    console.log(`   ${ok ? '✅' : '❌'} getRounds() → ${rounds} ${ok ? '(正确)' : '(应为11)'}`);
    ok ? passed++ : failed++;
  } catch (e) {
    console.log(`   ❌ getRounds 异常: ${e.message}`);
    failed++;
  }

  // 汇总
  console.log('\n' + '='.repeat(40));
  const total = passed + failed;
  console.log(`📊 总计: ${total} 用例 | ✅ 通过: ${passed} | ❌ 失败: ${failed}`);
  console.log(total === passed ? '\n🎉 全部通过!' : `\n⚠️  有 ${failed} 个失败`);
}

runTests().catch(e => console.error('测试框架异常:', e));

输出结果（从源码编译的 bcrypt_lib.node 上运行）：
在这里插入图片描述

🧪 bcrypt 测试用例
========================================

📌 测试 1: hash + compare 基本流程
    ✅ hash("test123") → compare → 正确
    ✅ hash("Hello@2024") → compare → 正确
    ✅ hash("aB3#xyZ!") → compare → 正确
    ✅ hash("密码123") → compare → 正确
    ✅ hash("(空)") → compare → 正确

📌 测试 2: 不同 saltRounds
    ✅ saltRounds=4 → $2b$4$zQX5l...
    ✅ saltRounds=10 → $2b$10$WrMpR...
    ✅ saltRounds=12 → $2b$12$VgCfD...

📌 测试 3: 同步 API (hashSync / compareSync)
    ✅ hashSync + compareSync 正常

📌 测试 4: 边界情况
    ✅ 空密码 hash+compare 正常

📌 测试 5: getRounds 解析 hash 轮数
    ✅ getRounds() → 11 (正确)

========================================
📊 总计: 10 用例 | ✅ 通过: 10 | ❌ 失败: 0

🎉 全部通过!

5 组测试覆盖了 10 个子用例，全部通过。无论是预编译 .node 还是源码编译的 bcrypt_lib.node，功能表现完全一致。

一个有意思的细节

新版 npm（10.x+）中，--build-from-source 已被废弃：

npm warn Unknown command: "--build-from-source"

正确的做法是：

# 方式一：删预编译二进制触发回退
rm -rf node_modules/bcrypt/prebuilds
npm rebuild bcrypt

# 方式二：直接调用 node-gyp
npm rebuild bcrypt --foreground-scripts

# 方式三：最底层
cd node_modules/bcrypt && npx node-gyp rebuild --verbose

--foreground-scripts 可以把编译过程的每一条 clang++ 命令都输出到终端，方便调试。

延伸实战：sqlite3 的移植教训

除了 bcrypt，我们还在同一台机器上移植了另一个 native 模块——sqlite3@6.0.1。这次遇到的情况完全不同，正好验证了工具链的健壮性。

首次安装：编译失败

npm install sqlite3

报错关键信息：

514 error make: ar: No such file or directory
514 error make: *** [../node-addon-api/nothing.target.mk:130: Release/obj.target/../node-addon-api/nothing.a] Error 127

在这里插入图片描述

根因分析

ar（GNU Archiver）是 binutils 的一部分，负责将 .o 目标文件打包为 .a 静态库。node-gyp 在编译 native 模块时，通过 Makefile 调用 ar 来创建中间静态库，但 Harmonybrew 默认的 devel-base 没有包含 ar。

为什么 bcrypt 没遇到这个问题？

模块安装路径结果
bcryptprebuild 预编译 → 直接下载 .node 二进制✅ 成功，零编译
sqlite3prebuild-install 超时 → 回退 node-gyp rebuild 源码编译❌ 缺少 ar 失败

bcrypt 的预编译路径完全绕过了 C++ 编译环节；而 sqlite3 在预编译下载超时后回退到源码编译，才暴露出 ar 缺失的问题。

修复

安装提供 ar 的工具包：

brew install binutils

或更全面的：

brew install llvm-gcc-compat binutils

验证：

which ar      # → /harmonybrew/bin/ar
ar --version  # → GNU ar (GNU Binutils) ...

重新安装

npm rebuild sqlite3 --foreground-scripts

这次编译链路完整走通：clang++ 编译 .cc → ar 打包 .a → clang++ 链接生成 .node，最终输出 added 57 packages，无任何 gyp ERR!。
在这里插入图片描述

测试验证

参照 bcrypt 的测试风格，为 sqlite3 编写了 10 组测试用例：

#测试项覆盖内容
1打开/关闭数据库文件创建、连接生命周期
2CREATE TABLE + INSERTDDL、参数化插入、lastID
3SELECT 查询db.all()、排序、行数验证
4参数化查询防 SQL 注入、db.get()
5UPDATE修改数据、this.changes
6DELETE删除前后行数对比
7事务BEGIN/COMMIT/ROLLBACK 可见性
8错误处理NOT NULL 约束违反捕获
9serialize 串行化执行顺序保证
10内存数据库:memory: 模式读写

全部 10 组通过：
在这里插入图片描述

🧪 sqlite3 测试用例
========================================
📌 测试 1: 打开和关闭数据库    ✅
📌 测试 2: 建表 + 插入数据     ✅
📌 测试 3: SELECT 查询         ✅
📌 测试 4: 参数化查询           ✅
📌 测试 5: UPDATE              ✅
📌 测试 6: DELETE              ✅
📌 测试 7: 事务                ✅
📌 测试 8: 错误处理            ✅
📌 测试 9: serialize 串行化    ✅
📌 测试 10: 内存数据库         ✅
========================================
📊 总计: 10 用例 | ✅ 通过: 10 | ❌ 失败: 0
🎉 全部通过!

sqlite3 移植的核心经验

  1. 预编译不是万能的——bcrypt 走预编译一路顺风，但 sqlite3 的预编译下载超时后就暴露了工具链缺口
  2. ar 是编译链路的关键一环——devel-base 包含了 clang++、make、python3，但缺少 binutils（ar、ld 等）。安装 binutils 即可补齐
  3. 源码编译路径验证了工具链的完整性——修复后 sqlite3 完整走通了 C++ 编译→静态库打包→链接的全流程，证明 Harmonybrew 工具链完全胜任 node-gyp native 模块的编译需求
  4. --foreground-scripts 是调试利器——能看到完整的 clang++ 编译命令和 ar 打包过程，快速定位缺失的工具

最终结论

因素角色
bcrypt@6.x 预编译策略关键因素——走预编译路径时零依赖安装
--tag-libc 构建参数生成了 -glibc/-musl 双变体，鸿蒙精确命中后者
鸿蒙系统是 ARM64 + musl与预编译包完美匹配，无需兼容层
devel-base（Harmonybrew 工具链）预编译路径未使用，但源码编译路径完整可用

所以这背后是两个好消息：

预编译路径：bcrypt@6.0.0 的构建者用 --tag-libc 为不同 libc 分别构建了变体，鸿蒙 PC 是 linux-arm64 + musl，node-gyp-build 精准命中了 bcrypt.musl.node——零编译，装完即用。

源码编译备胎：即使预编译二进制不存在（或被人删了），devel-base 工具链已就绪，直接 npm rebuild 能顺利从 .cc 源码编译出 .node 二进制。两条路都通。

对鸿蒙上 Node.js 开发者的参考

  • 优先选择支持 prebuild 的包，安装过程最省心
  • 即使包没有预编译，有 devel-base 工具链（clang + make + python3），大部分 node-gyp 模块也能从源码编译
  • bcrypt --tag-libc 是一个好实践——如果开发 native 模块，建议也加上这个参数，对齐不同 libc 环境下安装者的体验
  • 如果遇到 --build-from-source 报 unknown command，换成 --foreground-scripts，这是新 npm 的正确方式
  • 迁移 sqlite3 等模块的额外教训：安装 binutils 补全 ar 等归档工具，确保源码编译链路完整

📸 参考资料

标签
#harmonyos #sqlite #笔记 #nodejs #三方库移植
#鸿蒙PC
HarmonyOS鸿蒙PC三方库移植：Node.js 三方库鸿蒙 PC 移植指南
猫哥 的沉淀、积累、总结。天天学习，好好向上...c/c++,嵌入式 linux,Android,HarmonyOS，AIOT)
07-15 579
本文针对C/C++开发者在Node.js鸿蒙移植过程中遇到的常见技术误区进行澄清，提供了经过验证的优化方案。文章首先指出四个关键错误：1) OS=ohos环境变量对node-gyp无效；2) cross-env无法解决交叉编译问题；3) 交叉编译并非最优方案；4) node-gyp无内置鸿蒙支持。随后提出两条实践路线：优先推荐在鸿蒙PC上本机编译（路线A），详细说明了NDK环境配置方法；备选方案为交叉编译（路线B）。文章特别强调了HarmonyOS环境下HMDFS文件系统的编译目录优化建议，并推荐使用Har
HarmonyOS API 24 交互事件与动画效果技术详解
woshi_xiaoa的博客
07-16 181
本文深入解析HarmonyOS API 24中的交互事件与动画技术，涵盖点击事件、触摸事件、手势识别以及动画效果的实现。主要内容包括：1）交互事件体系（点击、触摸、手势等）及其工作原理；2）onClick事件的高级用法（防抖、条件点击、事件委托）；3）onTouch事件的详细实现与典型应用场景（拖拽操作、手势识别）；4）ArkUI动画系统的属性动画和显式动画技术。通过代码示例展示了如何实现流畅的交互体验和视觉反馈，为开发者提供HarmonyOS应用交互设计的完整技术方案。（摘要字数：150字）
HarmonyOS 实战 | 弹窗/提示框怎么做——Alert、Dialog、Toast 详解
2502_92709686的博客
07-17 254
HarmonyOS弹窗设计实践指南 本文系统介绍了HarmonyOS应用开发中的弹窗设计方法，通过生活场景类比三类弹窗场景（确认选择/轻提示/信息输入），提出基于ArkUI的弹窗实现方案。核心内容包括： 弹窗分类体系：将HarmonyOS弹窗分为内置对话框（AlertDialog/ConfirmDialog）、ActionSheet/toast提示和自定义弹窗（CustomDialog）三大类，分析各类适用场景。 数据驱动设计：提出先定义弹窗配置数据结构（DialogConfig接口），实现弹窗样式与行为的
鸿蒙原生 ArkTS 布局方式之 Stack 悬浮按钮布局（HarmonyOS NEXT / API 24）
langruotian的博客
07-14 431
本文基于HarmonyOS NEXT的ArkTS框架，深入探讨了使用Stack堆叠容器结合position绝对定位实现悬浮按钮(FAB)的完整方案。文章从FAB的交互价值切入，系统解析了Stack容器的Z轴层叠原理和position定位机制，提供了可落地的六步实现教程，并针对API 24严格模式下的典型报错给出解决方案。在进阶部分，作者详细阐述了多级FAB动画、渲染性能优化策略，横向对比了四种实现方案的优劣，同时覆盖了折叠屏等多设备适配要点。全文兼顾理论深度与实践指导性，附有完整可编译代码，为Harmony
鸿蒙日志与埋点实战：构建企业级日志收集方案
2501_93575716的博客
07-12 227
本文介绍了如何基于HarmonyOS NEXT的hilog模块构建企业级日志系统。文章首先分析了hilog的优缺点，指出其缺乏持久化和文件回滚能力，随后提出一个封装方案，通过Logger类实现日志分级控制、磁盘持久化、自动回滚和Crash监控四大功能。核心内容包括：1）设计支持多级别、多模块的日志配置体系；2）实现日志双写（控制台+文件）与自动文件切割；3）提供线程安全的高效写入机制。所有代码兼容HarmonyOS NEXT API 12+，可直接集成到项目中，为应用提供完整的日志采集能力。
HarmonyOS掌上记账APP开发实践第23篇： Refresh 下拉刷新 — 为记账应用打造流畅的数据刷新体验
春卷同学的博客
07-16 184
当默认刷新指示器无法满足 UI 需求时，可通过Scroll() { /* 内容区 */ }// 当下拉偏移量变化时，驱动自定义动画})结合 animateTo 和图形变换，可以实现旋转图标、进度条填充等自定义下拉动画效果。Refresh 组件为鸿蒙应用提供了声明式的下拉刷新能力，通过$$双向绑定简化了刷新状态管理。实际开发中，合理配置 friction 和 threshold 可以优化下拉手感，而自定义刷新动画则让加载过程更具品牌特色。
鸿蒙HarmonyOS LLM 流式输出实战 —— SSE 解析、增量 UTF-8 解码与 8 种流式事件
weixin_39706922的博客
07-14 689
文章覆盖六大主题：流式输出的三层挑战（协议/编码/语义）、Transport SPI 与鸿蒙 HTTP 的桥接（dataReceive/dataEnd/取消）、SseParser 逐行解帧（LF/CRLF/多行 data/注释/[DONE]）、IncrementalUtf8Decoder 的残字节保留（跨 chunk 多字节字符）、StreamAssembler 的字节→事件管道（8 种事件 + 终止状态机）、Provider 差异与流式重试
电影匹配引擎-基于鸿蒙的心情电影推荐应用开发实践
xd185578555的博客
07-13 173
摘要（150字）： 电影匹配引擎是一款基于鸿蒙系统的AI电影推荐应用，通过分析用户心情、类型偏好和时长需求，智能推荐匹配的电影。应用采用三层架构设计（界面层、业务层、数据层），使用TypeScript定义核心数据结构与状态管理，内置多场景Mock数据实现离线推荐。主要功能包括心情匹配（开心/伤感等）、类型筛选（喜剧/科幻等）和时长选择（90分钟内/不限等），每部电影附带个性化推荐理由。UI遵循鸿蒙设计规范，适配多端设备，为用户提供精准、便捷的观影推荐服务。
书单推荐官-基于鸿蒙的智能书籍推荐应用开发实践
z123457982146679的博客
07-17 41
《书单推荐官》是一款基于鸿蒙生态的AI智能书籍推荐应用，旨在解决用户在海量图书资源中精准选书的难题。该应用采用个性化推荐算法，通过分析用户兴趣、阅读目的和时间安排三个维度，智能匹配适合的书籍。核心功能包括分级推荐（入门/进阶/高阶）、多领域覆盖（文学/商业/历史等）以及详细的阅读建议。技术实现上采用鸿蒙多端适配架构，包含用户界面层、业务逻辑层和数据存储层，使用TypeScript严格定义数据结构，并通过状态管理优化用户体验。应用内置多场景Mock数据，支持离线运行，为不同阅读需求的用户提供定制化书单推荐方案
HarmonyOS趣味相机实战第11篇：从单摄切换升级前后双摄同开、能力探测与降级设计
2301_76810349的博客
07-15 241
基于 HarmonyOS ArkTS 趣味相机当前单摄 CameraKit 架构，设计 API 18+ 前后双摄同开升级路径，覆盖设备发现、并发能力探测、受限模式打开、双 Surface、双路拍照与不支持机型降级。
HarmonyOS 6.1 多模态AI交互实战：语音+图像混合搜索的“所想即所得”
listening777的博客
07-17 42
回顾上篇的“拍照搜同款”，本质是单模态AI（只有视觉输入）。但在真实电商场景中，用户的诉求往往是复合的：“拍这件外套，要L码的”（视觉+文本）“扫这个沙发，要北欧风格的”（视觉+语义）“找这个耳机，预算500以内”（视觉+数值约束）传统的解决方案是“串行处理”：先识别图像，再解析语音，最后合并结果。这种方式时延高（>800ms），且容易丢失上下文关联（比如语音说的“红色”到底指哪件商品）。HarmonyOS 6.1的多模态感知框架（Multimodal Awareness Kit）支持。
HarmonyOS 应用开发《掌上英语》第13篇:面向对象 vs 函数式：ArkTS 中的编程范式选择
weixin_69932715的博客
07-15 168
面向对象（class +@Trace）是 ArkTS 响应式 UI 的基础，适合数据模型、ViewModel 和业务实体函数式@Builder、单例工具类）在 UI 片段复用、工具服务和无状态逻辑中更简洁混合使用是最佳实践：数据层用 OOP 保证响应式，工具层用 FP 保证可测试性理解每种范式的设计意图和适用场景，才能写出既符合 ArkTS 平台特性又易于维护的代码。
藏头诗工坊-基于鸿蒙的AI藏头诗创作应用开发实践
xd185578555的博客
07-17 124
摘要： "藏头诗工坊"是一款基于鸿蒙生态的AI藏头诗创作应用，支持用户输入藏头词并选择风格（五言、七言、现代等）和情感（祝福、表白等），自动生成符合格律的藏头诗。应用采用三层架构设计（用户界面层、业务逻辑层、数据存储层），通过状态管理（@State）实现动态交互，并内置多场景Mock数据保证离线可用。核心功能包括藏头词分析、格律匹配和诗歌生成，最终输出包含标题、诗句、藏头词及释义的完整结果。应用适配鸿蒙多端设备，融合传统文化与AI技术，为用户提供便捷的诗意创作体验。
【共创季稿事节】HarmonyOS 7.0 ArkTS 声明式UI高级实战：自定义动画与手势系统
从事移动开发八年，csdn博客专家，阿里云特邀专家，华为云云享专家，高级网络信息安全工程师，大数据工程师（高级），python技术开发（高级），HarmonyOS 应用开发者高级认证，现在某学校任教。
07-17 718
7.0 可能支持类似 Android 的共享元素转场：页面 A 中的图片点击后，在页面 B 中从原位放大到全屏。// 7.0 推演：共享元素转场// 页面 A：缩略图列表@Entry@Componentbuild() {Grid() {${// 7.0 推演：共享元素转场 // 页面 A：缩略图列表 @ Entry @ Component struct GalleryPage {build() {Grid() {
从零设计鸿蒙 AI Agent SDK：ArkAgent 架构全解析
weixin_39706922的博客
07-13 547
文章覆盖六大主题：为什么需要 Agent SDK（裸调 API 的五个天花板）、模块边界设计（core/eval/entry 三模块分离 + 10 层内部分层）、Agent Loop 状态机（idle → preparing → callingModel → ... → completed 的完整生命周期）、核心契约设计（JSON 体系、消息模型、LLMClient SPI、工具契约、错误模型）、主数据流（从用户输入到最终回答的完整流转）、架构踩坑与设计教训。
鸿蒙分布式能力与超级终端实战：设备发现·数据同步·任务流转
最新发布
2501_93575716的博客
07-17 82
本文深入探讨了HarmonyOS NEXT的分布式能力架构与开发实践，聚焦超级终端技术实现。文章首先剖析了分布式软总线的四层架构（设备管理、协议适配、分布式调度、数据通道）及其协同机制，阐述了可信设备与协同设备的动态角色转换原则。随后通过ArkTS代码示例，详细演示了设备发现与信任组管理的实现方式，包括DeviceManager初始化、设备状态监听、信任代理启动等核心流程。该技术使多设备能智能协同，为开发者提供透明高效的分布式开发体验，是构建HarmonyOS生态互联能力的关键基础设施。
HarmonyOS ArkTS 模块化：5 种 Export/Import 方式全覆盖
weixin_57404083的博客
07-15 235
本文介绍了HarmonyOS 6.1及以上版本的ArkTS模块系统，重点演示了5种常用import/export方式。通过MathUtils.ets（命名导出+默认导出）和Constants.ets（常量模块+re-export）两个示例模块，展示了命名导入、默认导入、命名空间导入、常量导入和re-export导入的具体用法，并提供了运行结果截图验证。最后总结了每种导入方式的适用场景和优势，如命名导入适合tree-shaking优化，默认导入支持自定义别名，re-export可实现统一API入口等。文章还解
HarmonyOS 6.1 调试与问题定位实战：从Log到HiTrace的排错全景图
listening777的博客
07-14 245
在之前的系列中，我们写过@State数据不刷新、Marquee在iOS上卡顿、分布式流转失败等问题。当时为了篇幅，我只给出了“解决方案”，没展示“排查过程”。其实，找到Bug的原因比修复Bug更难。新手往往靠到处打印，或者在代码里“随机修改看运气”。而高手会熟练使用HiLog分级过滤HiTrace分布式追踪和SmartPerf性能分析。本文将揭示我在开发电商Demo时遇到的三个“灵异事件”及其排查全过程，这些工具能让你在面试中脱颖而出。调试不是“玄学”，而是一门科学。
02-Flutter 鸿蒙实战 02：Web 移植到 Flutter HarmonyOS 的页面结构
weixin_62511680的博客
07-16 193
把 Web 手机端的顶部栏、底部导航和业务入口迁移成 Flutter 页面骨架。
HarmonyOS APP实战-画图APP - 第17篇：打包发布与项目总结
漫步云端
07-13 111
本篇完成了画图APP的签名证书配置、Release HAP包生成与上架检查，生成了可直接安装的分发包。至此，整个画图APP从零开发到上架准备的全流程结束。基础能力：Canvas 2D绘制、触摸交互、形状/画笔/文字绘制（第1-7篇）图像处理：effectKit亮度/模糊/灰度调节、智能取色与色板生成、色彩空间转换与HDR支持（第8-10篇）高级功能：撤销/重做历史管理、图片导出与加载、本地数据库存储（第11-13篇）性能优化。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

特立独行的猫a

您的鼓励是我的创作动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值