OpenHarmony 鸿蒙 PC + CodeArts IDE 前端 Vite+Vue 完整开发环境，调用axios第三方库进行GET/POST请求数据

wanmeijuhao

319人浏览 · 2026-06-15 22:15:25

wanmeijuhao · 2026-06-15 22:15:25 发布

OpenHarmony 鸿蒙 PC + CodeArts IDE 前端 Vite+Vue 完整开发环境，调用axios第三方库进行GET/POST请求数据

本文完整梳理了ARM64架构鸿蒙PC（HarmonyOS/OpenHarmony6.1及以上），基于CodeArts IDE搭建Vite+Vue前端项目的全流程与疑难解决方案。项目实操中，Vite启动会出现rolldown原生模块权限拒绝报错，根源是鸿蒙系统拦截未签名二进制文件，最终解决方案为引入ohos-signpost自动签名工具，配置npm后置钩子，在依赖安装完成后自动为所有.node文件添加系统合法签名，消除权限校验拦截，最终实现CodeArts IDE内Vue+TS项目正常启动、调试，本文围绕ARM64架构鸿蒙PC（6.1及以上版本），完整讲解基于 CodeArts IDE、Harmonybrew、Vite+Vue+TS 的前端开发全流程，同时解决原生二进制模块权限、跨域调试等典型问题。

欢迎加入开源鸿蒙PC社区： https://harmonypc.csdn.net/

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

AtomGit 仓库地址：https://atomgit.com/OpenHarmonyPCDeveloper/ohos_node_vue_ts

一、什么是Harmonybrew 呢？

鸿蒙不自带 C/C++ 编译环境，且官方不提供鸿蒙版二进制包，所以这些库不能直接用，但它们支持自动编译，我们用 Harmonybrew 提供编译能力，就能让这些库在鸿蒙上自己编译自己，从而正常运行。

相信大多数人都用过 Mac系统，Homebrew 是 macOS / Linux 平台下最主流、最流行的开源命令行包管理器，圈内直接叫 brew。我们可以简单的来类比理解：

Windows：应用商店、360 软件管家、Chocolatey
Android：应用商店
Linux：apt / yum / dnf
macOS 专属标配：Homebrew

那么，Harmonybrew 是给 OpenHarmony/鸿蒙系统做的「Homebrew 移植版」，本质是一个命令行包管理器，目标是把 macOS/Linux 上最流行的 Homebrew 生态，完整搬到鸿蒙设备上（移植到了 OpenHarmony 操作系统上），这意味着，开发者可以在鸿蒙设备上使用熟悉的 brew install、brew search、brew update 等命令来安装和管理软件包。类似于Ubuntu上的apt-get或CentOS上的yum包管理工具，功能类似于Homebrew（Homebrew是Mac上最好用的包管理工具）。‌‌目前仅只支持 arm64（适配 ARM64 架构）的鸿蒙设备：

命令语法、使用逻辑几乎完全对齐 brew。
目标：让鸿蒙设备也拥有类似 Mac 的命令行软件管理能力。

概念	理解
Homebrew	Mac/Linux 下常用的软件安装工具，用 `brew install` 一键装软件、自动解决依赖。原生版，Mac/Linux 主流包管理器（鼻祖）
Harmonybrew	就是鸿蒙版 Homebrew，让你在鸿蒙 PC、开发板、容器里，也能用同样的 `brew` 命令装各种命令行工具和开发软件，社区基于 Homebrew 思路移植到 OpenHarmony / 鸿蒙的版本

Homebrew(Mac) → 设计思想被借鉴 → 衍生出 Harmonybrew(鸿蒙)

1.1 为什么需要 Harmonybrew？解决什么痛点？

原生鸿蒙（OpenHarmony）命令行环境极度精简，缺很多常用工具：

没有 apt/yum/brew 这种统一包管理器；
装 curl、wget、git、python、node、redis 等，只能：
- 手动下源码 → 编译 → 配环境变量 → 软链接；
- 依赖经常缺、编译报错、版本混乱、无法一键更新；
鸿蒙 PC、开发板、容器之间环境不一致，迁移麻烦。

那么，原生 OpenHarmony 的命令行环境功能比较精简，缺少大量常用开发工具，软件安装、依赖处理都只能手动操作，流程繁琐又容易出错，而 Harmonybrew 的出现，恰好补齐了这一短板：

一条命令安装、卸载、更新；
自动处理依赖；
统一软件仓库，版本可控；
尽量兼容 Homebrew 现有包（目前约 60% 可直接用）。

能力	原生 OpenHarmony	Harmonybrew
安装软件	手动编译/解压/配路径	`brew install` 一键搞定
依赖管理	手动找依赖、容易冲突	自动解析、安装依赖
版本管理	无统一机制，易混乱	可指定版本、一键升级
编译适配	常因平台/签名报错	内置适配工具，开箱即用
生态规模	极小（只有基础工具）	2000+ 包，接近 Homebrew

1.2 环境要求：

设备：鸿蒙 PC
系统：HarmonyOS 6.1+ / OpenHarmony 6.1+
架构：arm64

请添加图片描述

在使用之前需要开启一下"开发者选项"，我们可以找到"XXX的MateBookPro"左侧选项框中，在"关于本机"中，我们找到"软件版本"这里，连点 7 次鼠标，即可开启"开发者选项"，如下图所示：

请添加图片描述

后面我们通过重启电脑即可启用"开发者选项"。

请添加图片描述

接下来，我们在"隐私与安全"选项中，将"运行来自非应用市场的扩展程序"，将它开启即可。

1.3 卸载冲突软件：

如果 PC 中安装有 GitNext 和 DevBox 这两个应用，请先将它们卸载，这些应用可能与 Homebrew 的运行环境产生冲突。

请添加图片描述

1.4 安装命令（一行搞定） - 执行一键安装命令：

接着打开鸿蒙PC自带的终端，千万不要安装HiSH软件，一直提示我安装错误。

请添加图片描述

下面是 Harmonybrew（鸿蒙版 Homebrew）官方一键安装 Shell 脚本，也是鸿蒙设备部署 Harmonybrew 包管理器的唯一官方入口，基于标准 Homebrew 安装脚本深度适配 OpenHarmony/HarmonyOS 系统，全程自动化完成环境检测、依赖校验、程序下载、目录部署与基础配置，无需人工干预复杂操作，脚本会下载 Harmonybrew 本体，并且配置 PATH，自动修复常见环境问题。

请添加图片描述

zsh -c "$(curl -fsSL https://harmonybrew.atomgit.com/install.sh)"

1.一键部署 Harmonybrew：
- 替代手动下载、编译、配置等繁琐操作，在鸿蒙 PC、OpenHarmony 开发板、鸿蒙容器中自动安装包管理器核心程序，让鸿蒙设备拥有类似 macOS/Linux 的 brew 软件管理能力。
2.系统环境强校验：
- 提前检测系统类型、架构、Shell 环境、依赖工具，拦截不兼容环境、非法权限、冲突配置，避免安装失败。
3.鸿蒙系统专属适配：
- 针对鸿蒙 /system 目录只读、musl 库、权限机制、服务逻辑等特性做定制改造，解决原生 Homebrew 无法在鸿蒙运行的问题。
4.目录与环境自动配置：
- 自动创建专属安装目录、缓存目录，创建软链接，并在安装结束后给出环境变量配置指引，保证 brew 命令全局可调用。
5.多模式兼容：
- 支持交互式（日常手动安装）、非交互式（CI / 自动化脚本）、CI 环境等运行模式，适配个人使用与自动化部署场景。

1.5 配置环境变量：

把 Harmonybrew 的环境初始化代码写入你的终端配置文件 .zshrc，以后每次打开终端，都会自动加载 brew 命令，不用每次手动配置，总结就是把 Harmonybrew 配置进你的终端环境，让你每次打开 HiShell 都能直接使用 brew 命令，并且当前终端立即生效。

echo >> /storage/Users/currentUser/.zshrc
    echo 'eval "$(/storage/Users/currentUser/.harmonybrew/bin/brew shellenv)"' >> /storage/Users/currentUser/.zshrc
    eval "$(/storage/Users/currentUser/.harmonybrew/bin/brew shellenv)"

请添加图片描述

二、如何进行编译 Node.js addon？

鸿蒙系统（OpenHarmony）不能直接用那些带 C/C++ 代码的 npm 包（比如 sqlite3、node-sass），因为官方没给鸿蒙编译好版本。但这些包支持“自动编译”，我们用 Harmonybrew 工具就能在鸿蒙上自己编译，让它们正常运行。

2.1 什么是"带 C/C++ addon 的 npm 包"？

普通 npm 包 = 纯 JS 代码 → 所有系统都能直接跑

但有些包（sqlite3、node-sass、bufferutil）= JS + C/C++ 代码，但是C/C++ 代码必须编译成对应系统的二进制文件才能运行，就像：

Windows 要 .exe
Mac 要 .dylib
Linux 要 .so
鸿蒙要专门的 .so

但是这些库的官方，几乎没有给鸿蒙编译好文件，所以如果直接在鸿蒙上 npm install bufferutil 会报错、装不上、用不了，这些库也很聪明，比如找不到对应系统的预编译包，那就自动在你设备上现场编译，就像商店没给你切好的水果（预编译包），你可以自己拿刀切（本地实时构建）。

2.3 以 bufferutil 为例，整个流程到底在说什么？

由于极少有官方社区会为 OpenHarmony 平台提供预构建产物，导致这些库在鸿蒙设备上无法开箱即用。所幸的是，大多数 addon 都支持在缺少预构建包时自动回退到本地实时构建。

在 npm 中心仓中，部分三方库包含 C/C++ addon，如 sqlite3、node-sass、bufferutil 等。借助 Harmonybrew 提供的开发工具，我们可以在本地轻松完成这一构建过程，让这些库能够在 OpenHarmony 平台上工作。

以在鸿蒙 PC 的 HiShell 环境中实时构建三方库 bufferutil 为例，流程如下：

# 安装 node 和开发工具（在此场景中 python 也属于开发工具，因为 node-gyp 依赖它）
brew install node python devel-base

请添加图片描述

用 Harmonybrew 一次性安装：Node.js + Python + 鸿蒙编译器，让你能在鸿蒙上编译那些带 C/C++ 代码的 npm 包：

node = 房子（运行环境），运行 JavaScript，用 npm 装包，必须有它才能跑前端 / 后端项目。
python = 电动螺丝刀（依赖工具），安装 Python，是给 node-gyp 用的（node-gyp 是 Node.js 用来编译 C/C++ 代码的工具）。
devel-base = 全套木工工具（锯子、锤子、尺子……），安装 鸿蒙基础编译环境，包含：编译器（gcc/clang）、make 构建工具、C/C++ 头文件、系统库，没有它无法编译 C/C++ 代码。

请添加图片描述

2.4 安装bufferutil包：

在平时mac环境中，如何我们要使用一个全局的库，也是先创建一个目录，然后进入目录，安装 bufferutil 包，并检查是否安装成功，在拉包的过程中，一般为了防止网络不稳定的因素，我们一般会设置一个镜像源，比如淘宝镜像，这里在鸿蒙生态中，我们可以给 Node.js 换国内华为云镜像，让编译时下载文件不卡、不报错、不失败。

mkdir test-bufferutil
cd test-bufferutil

# 设置 Node.js 镜像
# node-gyp 会根据这个地址去下载 Node.js 头文件，这里设置成国内源以避免因网络问题下载失败
export npm_package_config_node_gyp_dist_url=https://mirrors.huaweicloud.com/nodejs

比如在编译 npm 包（sqlite3、bufferutil）时，node-gyp 必须下载 Node.js 头文件。在使用默认地址（国外服务器：慢、容易失败、报错），镜像设置后（华为云国内地址：飞快、稳定、100% 能下完）。

# 安装 bufferutil
# 由于 bufferutil 官方未提供 OpenHarmony 平台的预构建包，它会触发实时构建
npm install bufferutil

# 检查实时构建产物是否已经正确生成
# 注意，这个 .node 文件已经默认带有了代码签名（因为是用封装过的 ohos-sdk 工具链进行构建的），
# 所以 Node.js 运行时可以正常加载它
ls -l node_modules/bufferutil/build/Release/bufferutil.node

安装bufferutil 库，可以去检查一下：bufferutil 这个库，到底有没有在鸿蒙上编译成功、生成能用的文件，node_modules/bufferutil是安装的 bufferutil 库的内部路径，后缀.node表示是C/C++ 编译出来的二进制文件，只有这个文件存在，bufferutil 才能在鸿蒙上正常运行。

# 编写一个测试脚本，测试这个库能否正常工作
cat << 'EOF' > test.js
const bufferUtil = require('bufferutil');
const crypto = require('crypto');

const source = crypto.randomBytes(10);
const mask = crypto.randomBytes(4);

console.log(source, mask)
bufferUtil.mask(source, mask, source, 0, source.length);
console.log(source)
bufferUtil.unmask(source, mask);
console.log(source)
EOF

这段命令会在终端里新建一个名为 test.js 的测试文件，文件内的代码会加载刚编译好的 bufferutil 库和 Node 内置加密模块，生成随机数据与掩码，依次执行数据掩码加密、解密操作并全程打印内容，以此验证 bufferutil 库在当前环境下能否正常调用、运行。

# 执行测试脚本，观察结果
node test.js

请添加图片描述

三、如何在鸿蒙PC使用上使用CodeArts IDE进行前端开发？

CodeArts IDE（华为云码道 IDE）是华为云推出的、面向云原生开发的 AI 增强型桌面 IDE，主打 “AI 编程 + 华为云生态无缝打通”，对标 VS Code、IntelliJ，国内自研、免费 + 付费版均可使用。CodeArts IDE = VS Code + Copilot + 华为云控制台，本地 / 云端开发通吃，AI 帮你写代码、调云服务、管服务器，是国内云原生开发的强力工具。

我们可以先去应用市场中搜索并下载"CodeArts IDE"，然后安装。

请添加图片描述

3.1 mksh脚本解释器：

Harmonybrew（鸿蒙版 Homebrew）安装后，需要把它的 bin 目录加入系统 PATH，但是CodeArts IDE 内部调用时也会找不到 Harmonybrew 安装的工具（如 node、git、cmake 等）。

zsh 和 mksh 是两种不同的 Shell，各自读取自己的配置文件，互相不共享，如果只配一个，另一个环境就认不到 PATH，工具就用不了。为了让 HiShell 和 CodeArts IDE 都能调用到 Harmonybrew 安装的软件包，安装后需要将配 PATH 的操作分别写入 ~/.zshrc 和 ~/.mkshrc。

因为 HiShell 里面的脚本解释器是 zsh，CodeArts IDE 里面的脚本解释器是 sh(mksh)，这两个解释器使用的是不同的配置文件，CodeArts IDE 内部执行命令 / 脚本时用的 Shell 是 mksh，路径：/storage/Users/你的用户名/.mkshrc。

echo >> /storage/Users/currentUser/.mkshrc
echo 'eval "$(/storage/Users/currentUser/.harmonybrew/bin/brew shellenv)"' >> /storage/Users/currentUser/.mkshrc

请添加图片描述

给 mksh（CodeArts IDE 内置 Shell）配置 Harmonybrew 环境，让 CodeArts IDE 启动 Shell / 运行脚本时，自动识别 Harmonybrew 安装的各类软件，解决 command not found 问题。

3.2 npm安装Node.js 包：

因为 CodeArts IDE 自带的 node 版本过低，无法使用最新版本的 vite 和 rolldown，所以，我们需要安装最新版本的 Node.js，并使用 npm 安装 npm 包。

在CodeArts IDE中，安装好 Harmonybrew 之后，可以用它装一个最新版本的 node。

请添加图片描述

命令也是非常的简单：

brew install node

通过 Harmonybrew 在线安装 Node.js 运行环境，自动联网下载对应版本的 Node.js，自动解压、部署到 Harmonybrew 管理的目录，因为之前已经配置好了 PATH，安装完成后，在 HiShell、CodeArts IDE 里都能直接使用 node 和 npm 命令。

接下来使用命令来检查一下：

node -v   # 检查 node 版本
npm -v   # 检查 npm 版本

请添加图片描述

3.3 CodeArts IDE 跑通一个Vue的项目：

接下来我们可以打开CodeArts IDE，点击新建工程，创建一个新的项目。

请添加图片描述

并且在本地项目中创建一个code文件夹，用于放我们的代码code。

请添加图片描述

接下来，我们选择JavaScript模板，选择上面我们创建的code文件夹，并点击创建。

请添加图片描述

在 CodeArts IDE 的终端里面在当前目录直接搭建最新版 Vite 前端项目，执行命令：

npm create vite@latest

就会通过npm在当前目录初始化成一个 vite 工程，在运行命令后终端会出现 Install with npm and start now 这个选项，意思是是否马上用 npm 安装项目依赖并启动运行，这里选择 No，就只会生成项目基础文件，暂时不安装依赖、也不会启动项目。

请添加图片描述

$ npm create vite@latest
Need to install the following packages:
create-vite@9.0.7
Ok to proceed? (y) y

> demo@1.0.0 npx
> "create-vite"

│
◇ Project name:
│ vite-project
│
◇ Select a framework:
│ Vue
│
◇ Select a variant:
│ TypeScript
│
◇ Install with npm and start now?
│ No
│
◇ Scaffolding project in /storage/Users/currentUser/workspace/code/demo/vite-project...
│
└ Done. Now run:

  cd vite-project
  npm install
  npm run dev

初始化完成后，我们通过提示命令执行：

cd vite-project
npm install

请添加图片描述

安装依赖完成后，我们通过命令启动项目：

npm run dev

请添加图片描述

$ cd vite-project/                                                                                                                                                                               
$ npm install

added 47 packages, and audited 48 packages in 1m

8 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
$ npm run dev

> vite-project@0.0.0 dev
> vite

file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/binding-CXquf8ay.mjs:507
                if (loadErrors.length > 0) throw new Error("Cannot find native binding. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.", { cause: loadErrors.reduce((err, cur) => {
                                                 ^

Error: Cannot find native binding. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.
    at file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/binding-CXquf8ay.mjs:507:36
    at file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/binding-CXquf8ay.mjs:9:49
    at file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/parse-Bg2pr2Q5.mjs:3:46
    at ModuleJob.run (node:internal/modules/esm/module_job:439:25)
    at async node:internal/modules/esm/loader:646:26
    at async CAC.<anonymous> (file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/vite/dist/node/cli.js:706:27) {
  [cause]: Error: Error loading shared library /storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/@rolldown/binding-openharmony-arm64/rolldown-binding.openharmony-arm64.node: Permission denied
      at Object..node (node:internal/modules/cjs/loader:2040:18)
      at Module.load (node:internal/modules/cjs/loader:1596:32)
      at Module._load (node:internal/modules/cjs/loader:1398:12)
      at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
      at Module.require (node:internal/modules/cjs/loader:1619:12)
      at require (node:internal/modules/helpers:191:16)
      at requireNative (file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/binding-CXquf8ay.mjs:437:21)
      at file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/binding-CXquf8ay.mjs:475:18
      at file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/binding-CXquf8ay.mjs:9:49
      at file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/parse-Bg2pr2Q5.mjs:3:46 {
    code: 'ERR_DLOPEN_FAILED',
    cause: Error: Cannot find module './rolldown-binding.openharmony-arm64.node'
    Require stack:
    - /storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/binding-CXquf8ay.mjs
        at Module._resolveFilename (node:internal/modules/cjs/loader:1519:15)
        at wrapResolveFilename (node:internal/modules/cjs/loader:1073:27)
        at defaultResolveImplForCJSLoading (node:internal/modules/cjs/loader:1097:10)
        at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1124:12)
        at Module._load (node:internal/modules/cjs/loader:1296:5)
        at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
        at Module.require (node:internal/modules/cjs/loader:1619:12)
        at require (node:internal/modules/helpers:191:16)
        at requireNative (file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/binding-CXquf8ay.mjs:432:12)
        at file:///storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/binding-CXquf8ay.mjs:475:18 {
      code: 'MODULE_NOT_FOUND',
      requireStack: [
        '/storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/rolldown/dist/shared/binding-CXquf8ay.mjs'
      ]
    }
  }
}

Node.js v26.3.0

Vite 启动时加载 Rolldown 鸿蒙平台原生二进制模块失败，核心是文件权限不足，连带触发模块找不到、npm 可选依赖兼容问题，是 Rolldown 框架抛出的提示，native binding 指 .node 后缀的原生编译模块，是 C/C++ 编写的二进制文件，用来给 JS 提供底层能力。它检测不到对应平台的原生模块，同时判定大概率是 npm 处理可选依赖时存在已知缺陷，所以提示你删除依赖文件重装。

rolldown-binding.openharmony-arm64.node 是专门为 OpenHarmony + ARM64 架构编译的原生模块文件。OpenHarmony 系统对二进制可执行文件、原生模块有严格安全管控，即便之前执行过 ohos-signpost 签名，依然出现权限拒绝，常见场景：

文件下载 / 解压后，系统默认权限未放开，Node.js 没有读取、执行这个文件的权限；
CodeArts IDE 终端的运行身份、会话环境，和 HiShell 终端权限不一致；
签名操作未真正生效，签名后的权限配置丢失。

3.4 自动签名工具 ohos-signpost 引入工程中：

按下图所示，对 package.json 做修改，将自动签名工具 ohos-signpost 引入工程中：

{
  "name": "vite-project",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vue-tsc -b && vite build",
    "preview": "vite preview",
    "postinstall": "ohos-signpost"
  },
  "dependencies": {
    "ohos-signpost": "^1.0.2",
    "vue": "^3.5.34"
  },
  "devDependencies": {
    "@types/node": "^24.12.3",
    "@vitejs/plugin-vue": "^6.0.6",
    "@vue/tsconfig": "^0.9.1",
    "typescript": "~6.0.2",
    "vite": "^8.0.12"
  }
}

在dependencies依赖项里声明安装包 - “ohos-signpost”: “^1.0.2”：

ohos-signpost 就是鸿蒙原生模块自动签名工具，专门给项目里 .node 格式的二进制文件做系统合法签名，解决 OpenHarmony 下文件权限拒绝、无法加载的问题。
^1.0.2 是版本规则，代表安装 1.0.2 及同大版本下最新的小版本。

package.json 里的生命周期脚本 - “postinstall”: “ohos-signpost”：

postinstall 是 npm 内置钩子，含义是当项目依赖全部安装完成后，自动执行后面的命令。
配置后，每次执行 npm install 装完包，系统都会自动运行 ohos-signpost，批量给 node_modules 内所有鸿蒙原生模块补签名，不用手动敲命令，从根源避免签名缺失导致的启动报错。

请添加图片描述

安装依赖时先把 ohos-signpost 工具本身装到项目里，依赖安装结束的瞬间，自动调用这个工具完成签名，刚好适配你当前 OpenHarmony + Vite 的运行环境。

$ npm install

> vite-project@0.0.0 postinstall
> ohos-signpost

Signature successfully added to: /storage/Users/currentUser/workspace/code/demo/vite-project/node_modules/@rolldown/binding-openharmony-arm64/rolldown-binding.openharmony-arm64.node

added 2 packages, and audited 41 packages in 2s

ohos-signpost 工具成功给某个鸿蒙平台的原生二进制文件加上了系统签名，让它能在 OpenHarmony 上合法运行，自动遍历 node_modules 里的 .node 原生模块，给它们打上鸿蒙系统认可的签名，否则会报 “权限不足”“非法镜像” 而无法运行。在 npm install 之后自动执行（postinstall），Signature successfully added表示就是被签名的那个文件的绝对路径签名成功了。

rolldown-binding：Rolldown（类似 Rollup 的打包工具）的原生绑定模块
openharmony-arm64：专门给鸿蒙系统 + ARM64 架构编译的版本
.node：Node.js 原生 C/C++ 模块后缀，二进制文件

因为项目里用到了 Rolldown 的鸿蒙原生模块，ohos-signpost 自动给它签了名，现在这个文件可以在鸿蒙上正常加载执行了，Vite / Vue 项目可以正常使用 Rolldown 打包，不会因为原生模块无签名而报错，在 CodeArts IDE 的终端里面执行 npm install 安装依赖，可以看到自动签名工具 ohos-signpost 已经在正常工作，对 rolldown 的原生模块进行了签名。

请添加图片描述

最后，在 CodeArts IDE 的终端里面执行 npm run dev，启动 vite 的预览服务，项目可正常预览。

四、安装axios并且调用axios第三方库：

4.1 安装axios第三方库：

执行了 npm install axios 安装依赖，package.json 里已经包含了 ohos-signpost 依赖和 postinstall 钩子，终端里也正常跑完了安装流程，没有报错。

npm install axios

请添加图片描述

{
  "name": "vite-project",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vue-tsc -b && vite build",
    "preview": "vite preview",
    "postinstall": "ohos-signpost"
  },
  "dependencies": {
    "axios": "^1.18.0",
    "ohos-signpost": "^1.0.2",
    "vue": "^3.5.34"
  }
}

请添加图片描述

这个命令是安装 axios 依赖，同时会触发 postinstall 钩子，再执行 npm install 时，它才会真正扫描 .so/.node 文件并签名。

4.2 调用axios第三方库使用POST方法：

引入了 axios 网络请求库，在组件挂载完成后，自动发了一个 POST 请求到测试接口：

onMounted：Vue3 的生命周期钩子，意思是「组件挂载到页面上之后，自动执行里面的代码」。
axios：你刚安装的 HTTP 请求库，用来发网络请求，比原生 fetch 更方便、更强大。

axios.post('https://httpbin.org/post', {
        username: 'testuser',
        password: 'mypassword'
    }, {
        headers: {'Content-Type': 'application/json'}
    })
    .then(response => console.log(response.data));

请添加图片描述

触发时机：onMounted 里的代码，会在组件加载完成后自动执行，不用手动触发。
请求类型：axios.post 表示发送一个 POST 请求。
请求地址：https://httpbin.org/post 是一个公开的测试接口，会把你发过去的数据原封不动返回给你，专门用来调试网络请求。
请求体：{ username: ‘testuser’, password: ‘mypassword’ } 是你要发送给服务器的数据，会被自动序列化为 JSON 格式。
请求头：headers: { ‘Content-Type’: ‘application/json’ } 明确告诉服务器，你发的是 JSON 格式的数据。
结果处理：.then(response => console.log(response.data)) 表示请求成功后，把服务器返回的数据打印到浏览器控制台里，方便你调试。

可以直接在本地运行 npm run dev，打开浏览器控制台（F12），切换到「网络（Network）」标签页，就能看到这个 POST 请求的完整日志了。

CORS error：跨域资源共享错误，浏览器安全策略拦截了跨域请求
preflight post / 503：OPTIONS 预检请求返回 503 服务不可用

请添加图片描述

页面本身的 Vue 基础界面可以正常渲染展示，计数按钮也能正常使用，唯独通过 axios 发起的网络请求被浏览器拦截，核心根源是浏览器自带的同源跨域安全校验机制，本地开发页面运行在localhost:5173这个本地域名，请求目标是外部线上域名httpbin.org，两个访问源不一致就会触发 CORS 拦截。

请添加图片描述

4.3 调用axios第三方库使用GET方法：

这段代码运行在 Vue3 的 script setup 语法环境里，文件是项目的 HelloWorld 组件，页面渲染完成后就会自动执行网络请求逻辑，代码顶部先引入了 vue 提供的响应式变量创建工具 ref 和组件挂载完成生命周期钩子 onMounted，同时导入页面需要展示的几张静态图片资源以及刚安装完成的 axios 网络请求库。

请添加图片描述

onMounted 内部包裹的逻辑会在组件 DOM 完全渲染到浏览器页面后自动触发，这里使用 axios 发起了 GET 类型的网络请求，目标地址是 httpbin 提供的线上测试接口，params 配置项里填写了名为张三、年龄 25 的两组查询参数，axios 会自动把这些参数拼接在请求地址末尾形成完整访问链接，请求成功执行后进入 then 回调函数，接口返回的完整数据会被打印在浏览器控制台方便查看调试。

请添加图片描述

可以看到在浏览器控制台打印出了完整的接口返回数据，里面包含请求的参数和返回的数据，并且请求成功，没有 CORS 错误。

请添加图片描述

五、总结：

首先介绍了Harmonybrew，它是适配鸿蒙系统的包管理器，对标Mac平台的Homebrew，用来补齐鸿蒙原生终端缺少编译工具、运行环境的短板，可一键安装Node、Python、编译器等软件并自动处理依赖，大幅简化C/C++类npm包的本地编译流程。部署前需开启设备开发者选项、关闭软件冲突，通过官方脚本完成安装，并分别给zsh、mksh两种终端配置环境变量，保证HiShell和CodeArts IDE都能正常调用相关命令。

其次讲解了Node.js原生插件编译逻辑，部分npm包包含C/C++代码，需要编译为鸿蒙对应的.node二进制文件才能运行，借助Harmonybrew装好Node、Python及基础编译工具后，可自行完成这类插件的本地构建，搭配华为云镜像还能规避网络问题导致的编译失败。

接着是CodeArts IDE搭建Vite+Vue项目的核心环节，使用Harmonybrew安装新版Node后，通过脚手架初始化工程，直接启动项目会出现Rolldown原生模块权限拒绝报错，根源是鸿蒙系统对未签名二进制文件有安全拦截。解决方案是引入ohos-signpost自动签名工具，在package.json配置postinstall钩子，让依赖安装完成后自动为.node文件添加系统合法签名，彻底解决权限问题，保障项目正常启动运行。

最后演示了在项目中集成并使用Axios发起网络请求，分别测试POST、GET两种请求方式。本地浏览器调试时，POST请求因浏览器CORS跨域策略、测试接口服务异常出现拦截报错，改用GET请求后可正常调用接口、打印返回数据；该跨域限制仅存在于本地浏览器环境，项目部署至鸿蒙PC设备后则不会受此约束。