Tauri Demo 移植到鸿蒙PC上的交叉编译全流程实战总结

本文介绍了如何将 Tauri v2 + Vue 3 应用移植到 HarmonyOS PC / OpenHarmony 平台的完整流程。主要内容包括：项目准备：基于 richerfu/tauri-demo 项目，介绍 Tauri OHOS 分支的跨平台能力环境搭建：详细说明 Rust、Node.js、OHOS NDK 等工具链的配置方法构建过程：分步骤演示前端构建（Vue 3 + Vite）和

特立独行的猫a

610人浏览 · 2026-06-06 21:56:42

特立独行的猫a · 2026-06-06 21:56:42 发布

让 Tauri v2 + Vue 3 应用在 HarmonyOS PC / OpenHarmony 上完美运行

编译环境：Ubuntu 24.04 x86_64 · Rust 1.96.0 · OHOS SDK 6.1.0.27
项目源码：https://github.com/richerfu/tauri-demo

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

前言

2025 年5月8日，华为正式推出鸿蒙 PC 操作系统，HarmonyOS（OpenHarmony）完成了手机 → 平板 → PC 的全场景覆盖。随着鸿蒙生态向桌面端延伸，如何将现有的 Web + Rust 应用快速移植到鸿蒙平台成为开发者的热门话题。

Tauri 作为 Electron 的轻量化替代方案，以其精巧的体积和 Rust 高性能后端著称。而 richerfu/tauri 的 OpenHarmony 分支，使得 Tauri 应用可以跑在鸿蒙设备上——这意味着我们手中的 Vue / React 代码加上 Rust 后端，几乎不改就能编译成原生的鸿蒙应用。

本文以 richerfu/tauri-demo（Vue 3 + TypeScript + Rust）为蓝本，从 git clone 开始，完整记录了一次从零开始的鸿蒙 PC 交叉编译实践。文章面向有基础 Rust/Node 经验、但第一次接触鸿蒙开发的读者，力求每一步都可复现。

除此之外，还深入探讨了 Tauri 的体积迷思——为什么 demo 编译出来 142MB？Tauri 不是号称几个 MB 吗？答案都在第八章。

文章目录

前言

@[TOC]

1. 项目介绍与准备工作

1.1 这个项目是什么

1.2 前提条件

1.3 GitHub 下载加速（可选）

ghproxy.link

全局配置 Git 代理（推荐）

2. 克隆项目与安装依赖

2.1 克隆项目

2.2 安装前端依赖

2.3 预拉取 Rust 依赖（可选，但推荐）

2.4 项目使用的关键依赖一览

3. 前端构建

3.1 执行构建

3.2 构建输出

4. 鸿蒙交叉编译配置

4.1 创建配置文件

4.2 参数详解

4.3 验证配置

5. Rust 交叉编译

5.1 执行编译

5.2 编译流程全貌

5.3 编译产物验证

5.4 Debug vs Release 对比

6. 产物部署到 OHOS 项目

6.1 复制 .so 到正确位置

6.2 OHOS 项目如何加载这个 .so

6.3 完整的 OHOS 项目结构

7. 在鸿蒙PC上运行的完整流程

7.1 前提条件

7.2 导入 DevEco Studio

7.3 配置签名

7.4 构建 HAP

7.5 部署与运行

7.6 开发模式热更新

8. Tauri 体积深度分析

8.1 Tauri 不是号称很小吗？

8.2 原因一：Debug 编译包含完整调试符号

8.3 原因二：crate-type 滥用了

8.4 原因三：依赖了过多重型 crate

8.5 原因四：缺少 LTO 和体积优化

8.6 优化方案与预期效果

8.7 小结：Tauri 体积的真相

9. 常见问题与解决方案

9.1 ❌ `OHOS_NDK_HOME not set`

9.2 ❌ 链接时使用了宿主 `cc` 而非交叉编译器

9.3 ❌ `No space left on device`

9.4 ❌ Git 克隆超时或中断

9.5 ❌ `hvigor` 命令未找到

9.6 ❌ Tauri CLI 版本不匹配

10. 附录

10.1 完整操作流程速查

10.2 Profile 优化配置

10.3 精简 crate-type

10.4 关键技术要点速查

10.5 关键文件路径速查

10.6 参考链接

结语

1. 项目介绍与准备工作

1.1 这个项目是什么

richerfu/tauri-demo 是 Tauri OHOS 分支作者 richerfu 维护的一个 Demo 项目，用于演示 Tauri v2 应用如何在 OpenHarmony / HarmonyOS 上运行。

项目的核心是一份标准的 Tauri + Vue 3 项目，没有做任何鸿蒙特定的代码改动——这恰恰是 Tauri 跨平台能力的体现。

项目主要文件：

文件	作用
`src/`	Vue 3 前端（TypeScript）
`src-tauri/src/lib.rs`	Rust 后端：一个 `greet` 命令
`src-tauri/src/main.rs`	Rust 入口
`src-tauri/Cargo.toml`	Rust 依赖配置（指向 OHOS 分支）
`src-tauri/gen/ohos/`	Tauri CLI 自动生成的 OHOS 原生项目
`src-tauri/gen/ohos/entry/libs/arm64-v8a/`	Rust .so 的目标放置位置

项目截图：
在这里插入图片描述

1.2 前提条件

开始之前，请确保你的机器满足以下条件：

工具	最低版本	安装命令
Rust / Cargo	1.75+	`curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs \| sh`
OHOS Rust Target	—	`rustup target add aarch64-unknown-linux-ohos`
Node.js	18+	`nvm install 22` 或从 nodejs.org 下载
pnpm	8+	`npm install -g pnpm`
OHOS NDK	6.1+	从鸿蒙开发者官网下载解压

OpenHarmony的交叉编译工具链OHOS-SDK和Rust环境在Ubuntu24的linux环境的搭建，参见博文：
OHOS (OpenHarmony) 鸿蒙的Rust 交叉编译环境搭建指南

1.3 GitHub 下载加速（可选）

项目依赖的 crate 托管在 GitHub 上（包括 richerfu/tauri、richerfu/tao、richerfu/wry 等）。在国内网络环境下，克隆 GitHub 仓库可能非常缓慢甚至失败。

此时可以使用以下两种 GitHub 反向代理服务来加速：

ghproxy.link

https://ghproxy.link/ 是一个开源的 GitHub 代理服务。可以直接访问这个网址看使用介绍。

ghfast.top

https://ghfast.top/ ghproxy.link网站推荐使用的支持 Git 和 Raw 文件的代理加速：

# 通过代理克隆
git clone https://ghfast.top/https://github.com/richerfu/tauri.git

# 加速 raw 文件下载
curl -O https://ghfast.top/https://raw.githubusercontent.com/user/repo/main/file

全局配置 Git 代理（推荐）

如果你希望 Cargo 在拉取 Git 依赖时自动走代理，可以在 Git 全局配置中设置：

# 方法：替换 git 协议的 URL
git config --global url."https://ghfast.top/https://github.com/".insteadOf "https://github.com/"

配置后，Cargo 在 cargo build 时拉取 Git 依赖就会自动走代理，无需手动干预。

注意：代理服务仅对公开仓库有效，不需要 GitHub Token。如果速度正常，可以跳过此步。

2. 克隆项目与安装依赖

2.1 克隆项目

# 方式一：直连（推荐有国际网络环境的用户）
git clone https://github.com/richerfu/tauri-demo.git

# 方式二：走代理加速（国内用户推荐）
git clone https://ghfast.top/https://github.com/richerfu/tauri-demo.git

cd tauri-demo

2.2 安装前端依赖

pnpm install

这会安装 package.json 中声明的所有依赖：

npm 包	作用
`vue`	前端框架
`@tauri-apps/api`	Tauri 前端 JavaScript API
`@tauri-apps/plugin-opener`	文件打开插件
`@tauri-apps/cli`	Tauri 命令行工具（构建、打包）
`vite`	前端构建工具
`vue-tsc`	Vue TypeScript 类型检查

2.3 预拉取 Rust 依赖（可选，但推荐）

cd src-tauri
cargo fetch

cargo fetch 会预先下载 Cargo.toml 中声明的所有依赖（包括 Git 仓库中的 crate），但不进行编译。这样做的好处是：

提前发现网络问题（GitHub 仓库无法访问）
后续 cargo build 时不需要等待网络 I/O
如果使用代理，确保代理配置正确

如果国内网络较慢，建议先配置好 Git 代理（见 1.3 节）再执行 cargo fetch。

2.4 项目使用的关键依赖一览

以下依赖来自 src-tauri/Cargo.toml：

依赖	来源	作用
`tauri`	`richerfu/tauri` feat/open-harmony	鸿蒙化的 Tauri 框架核心
`tauri-build`	同上	Tauri 构建脚本
`tauri-runtime`	同上	Tauri 运行时抽象
`tauri-runtime-wry`	同上	基于 wry 的运行时实现
`tauri-utils`	同上	工具函数（配置、资源打包）
`tauri-macros`	同上	过程宏（`#[tauri::command]` 等）
`wry`	`richerfu/wry` (rev 指定)	跨平台 WebView 绑定——渲染前端
`tao`	`richerfu/tao` feat-ohos-webview	窗口创建与管理
`openharmony-ability`	`harmony-contrib`	鸿蒙 Ability 生命周期（Rust 版）
`napi-ohos` / `napi-derive-ohos`	crates.io	OHOS NAPI 绑定层
`tauri-plugin-opener`	crates.io	文件打开 / 外部链接
`serde` / `serde_json`	crates.io	序列化

这些依赖的传递依赖树非常庞大（涉及约 150-200 个 crate），首次编译时会全部下载并编译。

3. 前端构建

前端代码是标准的 Vite + Vue 3 项目，构建方式与普通 Web 开发完全一致。

3.1 执行构建

cd /path/to/tauri-demo
pnpm build

3.2 构建输出

$ vue-tsc --noEmit && vite build
vite v6.4.1 building for production...
✓ 18 modules transformed.
dist/index.html                  0.48 kB │ gzip:  0.30 kB
dist/assets/index-yfKK-ms3.css   1.40 kB │ gzip:  0.66 kB
dist/assets/index-DV24ggAs.js   63.47 kB │ gzip: 25.53 kB

前端产物仅约 65 KB（未压缩），会被 tauri-utils 在编译时打包进 Rust 二进制文件中，作为 WebView 加载的本地资源。

4. 鸿蒙交叉编译配置

要让 Rust 编译出 ARM64 架构的 OHOS 动态库（.so），需要告诉 Cargo 三件事：

目标架构是什么（aarch64-unknown-linux-ohos）
链接器用哪个（OHOS NDK 的 clang）
系统库在哪里（OHOS sysroot）

这些通过 .cargo/config.toml 来配置。

4.1 创建配置文件

mkdir -p src-tauri/.cargo

创建 src-tauri/.cargo/config.toml，写入：

# OHOS (OpenHarmony) 交叉编译配置
# 使用鸿蒙 NDK 中的 clang 作为链接器

[env]
OHOS_NDK_HOME = "/root/ohos-sdk/linux/native"

[target.aarch64-unknown-linux-ohos]
linker = "/root/ohos-sdk/linux/native/llvm/bin/aarch64-unknown-linux-ohos-clang"
rustflags = [
    "-C", "link-arg=--sysroot=/root/ohos-sdk/linux/native/sysroot",
]

4.2 参数详解

配置项	作用与原理
`[env].OHOS_NDK_HOME`	`ohos-arkui-sys`、`ohos-xcomponent-sys` 等原生 crate 的 `build.rs` 通过此变量定位 NDK。如果缺失，它们会直接 panic
`linker`	指定 Rust 编译器在汇编 + 链接阶段调用的外部链接器。必须指向 OHOS NDK 的 clang，它知道如何链接到 `libace_napi.z.so`、`libohweb.so` 等 OHOS 系统库
`--sysroot`	告诉 clang 去哪里找系统头文件（`*.h`）和系统库（`libc.so`、`libm.so` 等）。指向 OHOS SDK 中的 `sysroot` 目录

4.3 验证配置

运行一个快速检查，确认 Cargo 使用了正确的配置：

cd src-tauri
cargo build --target aarch64-unknown-linux-ohos -v 2>&1 | grep "linker="

输出应包含：

-C linker=/root/ohos-sdk/linux/native/llvm/bin/aarch64-unknown-linux-ohos-clang

如果显示的是 cc 或 gcc，说明 .cargo/config.toml 没有被正确读取——检查文件路径和格式。

5. Rust 交叉编译

5.1 执行编译

所有配置就绪后，执行交叉编译：

cd /path/to/tauri-demo

# Debug 编译（带调试信息，适合开发测试）
cargo build --target aarch64-unknown-linux-ohos \
            --manifest-path src-tauri/Cargo.toml

# Release 编译（优化+去符号，适合生产部署）
cargo build --target aarch64-unknown-linux-ohos \
            --manifest-path src-tauri/Cargo.toml \
            --release

首次编译会下载并编译所有依赖（150-200 个 crate），耗时约 5-15 分钟（视网络和 CPU 而定）。后续增量编译通常在 10-30 秒内完成。

5.2 编译流程全貌

当 Cargo 收到上述命令时，背后依次执行以下步骤：

① 解析依赖图

读取 Cargo.toml 及其所有传递依赖，构建完整的依赖树。

② 拉取源码

从 crates.io 和 Git 仓库下载所有依赖包的源代码。Git 依赖包括：

• richerfu/tauri (feat/open-harmony)   → Tauri 框架
• richerfu/tao (feat-ohos-webview)     → 窗口管理
• richerfu/wry (rev 814340ec)          → WebView 绑定
• harmony-contrib/openharmony-ability  → OHOS Ability 框架

③ 逐一编译 crate

每一个 crate 都会被 rustc 用 --target aarch64-unknown-linux-ohos 参数编译为 ARM64 的目标文件（.o），存放在 target/ 目录下。

④ 链接

最后一步，将所有 .o 文件通过 OHOS clang 链接成一个 .so，并链接 OHOS 系统库：

-lohweb              # 鸿蒙 WebView 引擎
-lace_napi.z         # NAPI 原生接口
-lace_ndk.z          # NDK 接口
-lnative_display_manager  # 显示管理
-lohinputmethod      # 输入法
-lunwind -lc         # C 运行时

5.3 编译产物验证

编译完成后，产物在：

src-tauri/target/aarch64-unknown-linux-ohos/debug/
└── libtauri_demo_lib.so

使用 file 命令确认架构：

$ file libtauri_demo_lib.so
libtauri_demo_lib.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV),
dynamically linked, with debug_info, not stripped

关键信息解读：

字段	含义
`ELF 64-bit LSB`	64 位小端 ELF 格式
`ARM aarch64`	✅ 目标架构正确（ARM64）
`dynamically linked`	动态链接库（.so）
`with debug_info`	包含调试符号（Debug 构建）
`not stripped`	符号表未剥离

5.4 Debug vs Release 对比

维度	Debug	Release
编译命令	`cargo build`	`cargo build --release`
产物路径	`target/…/debug/`	`target/…/release/`
调试信息	✅ 完整	❌ 剥离
文件大小	~142 MB	~12-15 MB
编译时间	快（无优化）	慢（LTO + 优化）
运行性能	慢（未优化）	快（O3/Oz）

6. 产物部署到 OHOS 项目

6.1 复制 .so 到正确位置

OHOS 原生项目（由 tauri init 自动生成）的目录结构已经预留了原生库的位置：

# 创建目标架构目录
mkdir -p src-tauri/gen/ohos/entry/libs/arm64-v8a

# 复制 Rust 编译产物
cp src-tauri/target/aarch64-unknown-linux-ohos/debug/libtauri_demo_lib.so \
   src-tauri/gen/ohos/entry/libs/arm64-v8a/

libs/arm64-v8a/ 是 OHOS 存放 64 位 ARM 原生库的标准路径，与 Android 的 lib/arm64-v8a/ 对应。

6.2 OHOS 项目如何加载这个 .so

EntryAbility.ets 中声明了加载的模块名：

// src-tauri/gen/ohos/entry/src/main/ets/entryability/EntryAbility.ets
import { NativeAbility } from '@ohos-rs/ability'

export default class EntryAbility extends NativeAbility {
  public moduleName: string = "tauri_demo_lib"   // → libtauri_demo_lib.so
  public defaultPage: boolean = true;
  // ...
}

当 OHOS 应用启动时，openharmony-ability 框架会自动在 libs/arm64-v8a/ 中查找 libtauri_demo_lib.so 并加载。加载后，Rust 端的 main() 函数被调用，进而启动 Tauri 应用窗口。

6.3 完整的 OHOS 项目结构

gen/ohos/entry/
├── libs/
│   └── arm64-v8a/
│       └── libtauri_demo_lib.so    ← Rust 交叉编译产物
├── src/main/
│   ├── cpp/                        ← C++ NAPI 胶水层（由 hvigor 编译）
│   │   ├── CMakeLists.txt
│   │   └── napi_init.cpp
│   ├── ets/
│   │   ├── entryability/
│   │   │   └── EntryAbility.ets    ← 入口 Ability
│   │   └── pages/
│   │       └── Index.ets           ← 首页
│   └── module.json5                ← OHOS 模块配置
├── build-profile.json5             ← hvigor 构建配置
├── hvigorfile.ts                   ← hvigor 构建脚本
└── oh-package.json5                ← OHOS 包配置

7. 在鸿蒙PC上运行的完整流程

7.1 前提条件

条件	说明
开发机	Windows / macOS（安装 DevEco Studio）
DevEco Studio	华为官方 IDE（内含 hvigor 构建工具）
鸿蒙PC设备	或 HarmonyOS 模拟器（DevEco Studio 自带）
USB 调试 / hdc	用于连接真机
签名证书	DevEco Studio 可自动生成调试证书

为什么不在 Linux 上直接打包？ HAP（HarmonyOS Ability Package）的打包工具 hvigor 只随 DevEco Studio 分发，当前没有独立命令行版本。当前 Linux 环境（无 GUI）不具备运行 hvigor 的条件。（其实是有办法的，待研究）

7.2 导入 DevEco Studio

将 src-tauri/gen/ohos/ 目录复制到 Windows/macOS 开发机
打开 DevEco Studio → File → Open → 选择 ohos/ 目录
DevEco Studio 会自动识别这是一个 OHOS 工程

7.3 配置签名

签名是 OHOS 应用安装到真机的必要步骤：

DevEco Studio 自动配置：首次打开项目时，IDE 会提示"未签名"。点击 Sign In → 登录华为开发者账户 → IDE 自动生成调试证书
手动配置：在 build-profile.json5 中添加：

{
  app: {
    signingConfigs: [
      {
        name: "default",
        material: {
          certificateFile: "./cert.cer",
          keyStoreFile: "./key.p12",
          keyAlias: "mykey",
          keyPwd: "******",
          storePwd: "******"
        }
      }
    ]
  }
}

7.4 构建 HAP

方式一（IDE）：Build → Build HAP(s) → Build App Bundle(s)
方式二（命令行，需配置 hvigor 环境）：
```
cd ohos
hvigorw assembleHap
```

产物输出到：entry/build/default/outputs/default/entry-default.hap

7.5 部署与运行

# 连接鸿蒙PC设备（USB / 网络）
hdc install entry-default.hap

# 启动应用
hdc shell aa start -a EntryAbility -b com.ranger.tauri_demo

也可以在鸿蒙PC的应用列表中找到 “tauri-demo” 图标点击启动。

7.6 开发模式热更新

在开发阶段，可以利用 Vite 的 HMR 实现前端代码的实时刷新：

# 在开发机上启动 Vite dev server
TAURI_DEV_HOST=192.168.1.100 pnpm dev    # 监听局域网，端口 1420

鸿蒙设备上的 Tauri 应用启动时，会连接 http://192.168.1.100:1420 加载前端。修改 Vue 代码后，设备页面会自动热更新，无需重新编译 Rust。

8. Tauri 体积深度分析

8.1 Tauri 不是号称很小吗？

这是 Tauri 最深入人心的宣传点——比 Electron 小 20 倍。真实数据如下：

框架	Hello World 体积	运行时
Electron	~120-150 MB	Chromium + Node.js 全捆绑
Tauri (桌面)	~3-8 MB	使用系统 WebView + Rust 原生
Tauri + 复杂前端	~5-15 MB	前端资源内嵌

所以当我们的 Debug 产物达到 142 MB 时，确实值得追问：问题出在哪？

8.2 原因一：Debug 编译包含完整调试符号

这是 最大的单一体积来源。

$ file libtauri_demo_lib.so
... with debug_info, not stripped

Rust Debug 编译会注入 DWARF 格式的调试符号表：每个函数名、变量名、行号信息都被完整保留。这些符号在 ARM64 目标上尤其庞大。

量化分析：

项目	Debug	Release（估算）
调试符号	~127 MB	0（strip 后）
代码 + 数据	~15 MB	~12-15 MB
总计	~142 MB	~12-15 MB

结论：Debug 版的 142 MB 中，约 90% 是调试信息，不是真正的代码体积。

8.3 原因二：crate-type 滥用了

[lib]
crate-type = ["staticlib", "cdylib", "rlib"]

对于 OHOS 目标，只需要 cdylib（C 动态链接库）。多余的：

crate-type	作用	OHOS 是否需要
`cdylib`	产生 `.so` —— 主产物	✅ 核心
`staticlib`	产生 `.a` 静态库	❌ 不需要，增加编译量
`rlib`	Rust 内部库格式	❌ 不需要，占 target 空间

修复方法：

[lib]
crate-type = ["cdylib"]

8.4 原因三：依赖了过多重型 crate

对比标准 Tauri v2 桌面项目的依赖树，本项目的 OHOS 分支引入了大量桌面平台默认开启、但对 OHOS 无意义的重型 crate：

# 以下依赖在最终二进制中占据了大量空间

reqwest + hyper + tokio          # HTTP 客户端 —— ~16 MB
  │ 本意：桌面端通过 HTTP 下载资源
  └─ OHOS 是否需要？→ 不需要（资源通过 HAP 打包）

zbus + zvariant                  # Linux D-Bus IPC —— ~5 MB
  │ 本意：桌面端通过 D-Bus 通知/文件选择
  └─ OHOS 是否需要？→ 不需要（OHOS 没有 D-Bus）

icu_properties + icu_normalizer  # ICU 国际化 —— ~7 MB
  │ 本意：URL 模式中的 Unicode 处理
  └─ OHOS 是否需要？→ 可以简化（使用轻量替代）

brotli + brotli-decompressor     # Brotli 压缩 —— ~2 MB
  │ 本意：资源包压缩
  └─ OHOS 是否需要？→ Tauri 资源打包需要，保留

serde_with + erased-serde        # 序列化增强 —— ~1 MB
urlpattern + regex               # URL/正则匹配 —— ~3 MB
json-patch + jsonptr             # JSON 操作 —— ~0.5 MB
async-process + blocking         # 进程管理 —— ~1 MB

这些依赖从哪来的？（调用链分析）

tauri-plugin-opener
  └─ reqwest → hyper → tokio → ...

tauri-runtime-wry (Linux 桌面 feature)
  └─ zbus → zvariant → enumflags2 → ...

urlpattern
  └─ icu_properties → icu_normalizer → icu_locale → ...

tauri-utils
  └─ brotli → brotli-decompressor
  └─ urlpattern → (上面 ICU 链)
  └─ json-patch → jsonptr

根因：OHOS 分支的 Cargo.toml 继承了桌面版的 feature 配置，没有做平台裁剪。很多 crate 在 OHOS 上不会被实际执行，但仍然被编译进了二进制。

8.5 原因四：缺少 LTO 和体积优化

当前 Cargo.toml 中没有任何 [profile.release] 优化配置。默认 Release 配置仅做速度优化（-C opt-level=3），不做链接时优化和体积优化。

对比有无优化的差异：

配置	对体积的影响
默认 Release	基准（~12-15 MB）
`lto = true`	-15~25%：链接时跨 crate 死代码消除
`opt-level = "z"`	-5~10%：以速度换体积
`strip = "symbols"`	-5~10%：去除 release 符号
`codegen-units = 1`	-5~10%：允许更大范围的内联
`panic = "abort"`	-5~15%：去掉 unwind 表

8.6 优化方案与预期效果

将以下配置加入 src-tauri/Cargo.toml 末尾：

[profile.release]
lto = true                 # 链接时优化
opt-level = "z"            # 优化体积（等效 -Oz）
strip = "symbols"          # 自动 strip
codegen-units = 1          # 单码块单元
panic = "abort"            # abort 而非 unwind

各方案预期效果：

方案	预期体积	相比 Debug
❌ 当前 Debug（142 MB）	142 MB	—
① 只做 Release	~12-15 MB	-90%
② ① + LTO + strip + Oz	~5-8 MB	-95%
③ ② + 精简 crate-type	~5-8 MB（相同）
④ ③ + 裁剪依赖（移除 zbus）	~3-5 MB	-97%
⑤ 纯 Hello World（理论极限）	~2-3 MB	-98%

8.7 小结：Tauri 体积的真相

Tauri 确实很小——优化后 5-8 MB 的体量在跨平台框架中依然是顶尖水平
Debug 体积不代表真实体积——142 MB 中 90% 是调试符号
OHOS 分支尚未做平台精简——桌面端的重型依赖（D-Bus、ICU 等）被无差别编译进了 OHOS 二进制
优化空间巨大——三步操作（Release + LTO + strip）即可从 142 MB 降到 5-8 MB

9. 常见问题与解决方案

9.1 ❌ `OHOS_NDK_HOME not set`

现象：编译早期直接 panic 退出。

thread 'main' panicked at build.rs:4:42:
OHOS_NDK_HOME not set: NotPresent

原因：ohos-arkui-sys 等 crate 的 build.rs 需要在编译时找到 NDK 路径，但该环境变量未设置。

解决：

# 在 .cargo/config.toml 中
[env]
OHOS_NDK_HOME = "/path/to/ohos-sdk/linux/native"

或命令行传入：

OHOS_NDK_HOME=/path/to/ohos-sdk/linux/native cargo build --target aarch64-unknown-linux-ohos

9.2 ❌ 链接时使用了宿主 `cc` 而非交叉编译器

现象：编译到链接步骤时报错。

/usr/bin/ld: ... Relocations in generic ELF (EM: 183)
/usr/bin/ld: ... file in wrong format

原因：EM: 183 是 ARM 架构的 ELF 标识。宿主机的 /usr/bin/ld（x86_64 链接器）无法处理 ARM64 的目标文件。

排查：验证 Cargo 使用的 linker：

cargo build --target aarch64-unknown-linux-ohos -v 2>&1 | grep "linker="

如果输出 -C linker=cc 或 -C linker=gcc，说明 .cargo/config.toml 未被正确读取。

解决：

确认配置文件位于 src-tauri/.cargo/config.toml（不是 src-tauri/.cargo/config，不是项目根目录的 .cargo/）
确认配置文件格式合法（TOML 语法）

可以通过环境变量覆盖确认：

CARGO_TARGET_AARCH64_UNKNOWN_LINUX_OHOS_LINKER=/path/to/ohos-clang cargo build

9.3 ❌ `No space left on device`

现象：编译中途失败，出现 “No space left on device”。

原因：Debug 编译需要在 target/ 目录下生成大量中间文件，占用 3-5 GB。当磁盘容量不足时，链接步骤无法写入最终的 .so。

解决：

# 1. 清理 Debug 产物（保留 release 或反之）
rm -rf src-tauri/target/aarch64-unknown-linux-ohos/debug/
rm -rf src-tauri/target/debug/

# 2. 清理 Cargo 包缓存
rm -rf ~/.cargo/registry/cache/
rm -rf ~/.cargo/git/db/

# 3. 清理 npm/pnpm 缓存
npm cache clean --force
rm -rf ~/.npm/
rm -rf ~/.cache/pnpm/

# 4. 清理系统临时文件与包缓存
rm -rf /tmp/*
apt-get clean

# 5. 检查释放后的空间
df -h /

建议编译前确保至少 10 GB 空闲磁盘空间。

9.4 ❌ Git 克隆超时或中断

现象：cargo build 时卡在 “Updating git repository” 步骤，或出现：

error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

原因：GitHub 的 HTTP/2 传输在国内网络环境下可能不稳定，尤其大仓库的 depth=1 克隆容易超时。

解决：

# 方案一：使用 HTTP/1.1 并增大 postBuffer
git -c http.version=HTTP/1.1 -c http.postBuffer=524288000 clone --depth 1 <repo-url>

# 方案二：使用代理（Git 全局配置，推荐）
git config --global url."https://ghfast.top/https://github.com/".insteadOf "https://github.com/"

9.5 ❌ `hvigor` 命令未找到

现象：打包 OHOS 应用时找不到 hvigor 或 hvigorw。

原因：hvigor 不独立分发，只作为 DevEco Studio 的一部分发布。

解决：在 DevEco Studio（Windows/macOS）中打开 gen/ohos/ 目录，使用 IDE 的 Build 菜单进行 HAP 打包。

9.6 ❌ Tauri CLI 版本不匹配

现象：运行 npx tauri build 时报错：

Found version mismatched Tauri packages.
tauri (v2.8.5) : @tauri-apps/api (v2.9.1)

原因：npm 上的 @tauri-apps/cli（官方版）与 Cargo.toml 中引用的 richerfu/tauri OHOS 分支版本不同：

组件	来源	版本
Rust `tauri` crate	`richerfu/tauri` (OHOS 分支)	2.8.5
npm `@tauri-apps/cli`	npm registry (官方)	2.9.6

影响：官方 CLI 不知道如何构建 OHOS 目标，因此对于本项目的 OHOS 编译，直接使用 cargo build 即可，不需要 Tauri CLI 参与。

10. 附录

10.1 完整操作流程速查

# ====== 第一步：环境准备 ======
rustup target add aarch64-unknown-linux-ohos
# 确保 OHOS NDK 已解压到 /root/ohos-sdk/

# ====== 第二步：克隆项目 ======
git clone https://ghfast.top/https://github.com/richerfu/tauri-demo.git
cd tauri-demo

# ====== 第三步：安装前端依赖 ======
pnpm install

# ====== 第四步：构建前端 ======
pnpm build

# ====== 第五步：配置交叉编译 ======
mkdir -p src-tauri/.cargo
# 编辑 src-tauri/.cargo/config.toml（内容见 4.1 节）

# ====== 第六步：Rust 交叉编译 ======
cargo build --target aarch64-unknown-linux-ohos \
            --manifest-path src-tauri/Cargo.toml

# ====== 第七步：复制 .so 到 OHOS 项目 ======
mkdir -p src-tauri/gen/ohos/entry/libs/arm64-v8a
cp src-tauri/target/aarch64-unknown-linux-ohos/debug/libtauri_demo_lib.so \
   src-tauri/gen/ohos/entry/libs/arm64-v8a/

# ====== 第八步：在 DevEco Studio 中打包 HAP ======
# 打开 src-tauri/gen/ohos/ → Build HAP → 部署到设备

10.2 Profile 优化配置

在 src-tauri/Cargo.toml 末尾追加：

[profile.release]
lto = true
opt-level = "z"
strip = "symbols"
codegen-units = 1
panic = "abort"

10.3 精简 crate-type

# 修改前
[lib]
name = "tauri_demo_lib"
crate-type = ["staticlib", "cdylib", "rlib"]

# 修改后
[lib]
name = "tauri_demo_lib"
crate-type = ["cdylib"]

10.4 关键技术要点速查

知识点	说明
目标架构	`aarch64-unknown-linux-ohos`
交叉链接器	OHOS NDK 的 `aarch64-unknown-linux-ohos-clang`
系统库位置	OHOS NDK 的 `sysroot/` 目录
关键环境变量	`OHOS_NDK_HOME`
产物格式	`.so`（动态共享库）
OHOS libs 路径	`gen/ohos/entry/libs/arm64-v8a/`
入口 Ability	`EntryAbility.ets` → `moduleName: "tauri_demo_lib"`
HAP 打包工具	DevEco Studio（含 hvigor）
设备连接工具	`hdc`（OHOS SDK toolchains/ 下）

10.5 关键文件路径速查

文件	路径
交叉编译配置	`src-tauri/.cargo/config.toml`
Rust 业务源码	`src-tauri/src/lib.rs`
Rust 入口	`src-tauri/src/main.rs`
Rust 依赖配置	`src-tauri/Cargo.toml`
OHOS 入口 Ability	`src-tauri/gen/ohos/entry/src/main/ets/entryability/EntryAbility.ets`
OHOS 首页	`src-tauri/gen/ohos/entry/src/main/ets/pages/Index.ets`
OHOS 构建配置	`src-tauri/gen/ohos/entry/build-profile.json5`
OHOS 模块配置	`src-tauri/gen/ohos/entry/src/main/module.json5`
Rust 编译产物	`target/aarch64-unknown-linux-ohos/debug/libtauri_demo_lib.so`
OHOS 原生库目录	`gen/ohos/entry/libs/arm64-v8a/`

10.6 参考链接

项目源码：richerfu/tauri-demo — 本文编译的源项目
Tauri OHOS 分支：richerfu/tauri feat/open-harmony
OHOS 化 Tao：richerfu/tao feat-ohos-webview
OHOS 化 Wry：richerfu/wry
OHOS Ability Rust 绑定：harmony-contrib/openharmony-ability
GitHub 加速代理：ghproxy.link / ghfast.top
Tauri v2 官方文档：https://v2.tauri.app/
OpenHarmony 官方文档：https://gitee.com/openharmony/docs
HarmonyOS 开发者官网：https://developer.harmonyos.com/
Tauri + 鸿蒙PC：在鸿蒙系统上运行跨平台桌面应用

结语

从实践的角度看，在 Linux 上交叉编译 Tauri 到鸿蒙 ARM64 已经是一条可行的技术路径。

回看整个流程：

git clone → pnpm install → pnpm build → cargo build → copy .so → DevEco Studio → hdc install

涉及的步骤不算少，但每一步都有明确的目标和可验证的产出。Rust 扎实的交叉编译能力、OHOS NDK 完备的工具链、以及 richerfu/tauri 社区的持续推动，三者叠加使得"一次编写，多端运行"（Linux / Windows / macOS / Android / iOS / HarmonyOS）正在从口号走向现实。

当前 OHOS 分支仍处于早期阶段，还有一些明显的"糙点"：

依赖树未做平台裁剪——桌面端的重型依赖（D-Bus、ICU 等）被无差别编译进 OHOS 二进制
体积优化靠手动——需要开发者自行配置 LTO、strip 等 profile 优化
HAP 打包依赖 DevEco Studio——尚无法在纯命令行环境中完成端到端构建

但这些都不是结构性障碍，而是成熟度问题。随着更多开发者加入、社区反馈推动迭代，这些问题都会逐步收窄。

对于希望在 2026 年抢占鸿蒙桌面生态先机的团队来说，现在就是了解它、尝试它的最佳时机。

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

开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

KaihongOS 5.0 X86 桌面版系统介绍与完整安装教程

开源鸿蒙跨平台开发者社区

前端超能力：让浏览器听你指挥，深入WebAssembly加速、性能嗅探、跨端心智模型等前端超能力技能

开源鸿蒙跨平台开发者社区

OpenHarmony Fetch 网络请求实战：接口请求与数据解析全教程

应用开发离不开网络交互，从首页商品、资讯加载到登录提交，都需要调用后端接口。OpenHarmony 原生使用fetch实现 http/https 网络请求，无需额外引入三方库，支持 GET、POST、请求头配置、JSON 解析。本文讲解基础请求、参数传递、异常捕获，搭配真实模拟接口，结合前面 Preferences、ArkUI 组件完成网络数据列表展示实战。开发前置：配置网络权限项目目录→ mo

开源鸿蒙跨平台开发者社区

所有评论(0)

查看更多评论

特立独行的猫a

@qq8864

已为社区贡献19条内容

Tauri Demo 移植到鸿蒙PC上的交叉编译全流程实战总结

特立独行的猫a

前言

文章目录

1. 项目介绍与准备工作

1.1 这个项目是什么

1.2 前提条件

1.3 GitHub 下载加速（可选）

ghproxy.link

全局配置 Git 代理（推荐）

2. 克隆项目与安装依赖

2.1 克隆项目

2.2 安装前端依赖

2.3 预拉取 Rust 依赖（可选，但推荐）

2.4 项目使用的关键依赖一览

3. 前端构建

3.1 执行构建

3.2 构建输出

4. 鸿蒙交叉编译配置

4.1 创建配置文件

4.2 参数详解

4.3 验证配置

5. Rust 交叉编译

5.1 执行编译

5.2 编译流程全貌

5.3 编译产物验证

5.4 Debug vs Release 对比

6. 产物部署到 OHOS 项目

6.1 复制 .so 到正确位置

6.2 OHOS 项目如何加载这个 .so

6.3 完整的 OHOS 项目结构

7. 在鸿蒙PC上运行的完整流程

7.1 前提条件

7.2 导入 DevEco Studio

7.3 配置签名

7.4 构建 HAP

7.5 部署与运行

7.6 开发模式热更新

8. Tauri 体积深度分析

8.1 Tauri 不是号称很小吗？

8.2 原因一：Debug 编译包含完整调试符号

8.3 原因二：crate-type 滥用了

8.4 原因三：依赖了过多重型 crate

8.5 原因四：缺少 LTO 和体积优化

8.6 优化方案与预期效果

8.7 小结：Tauri 体积的真相

9. 常见问题与解决方案

9.1 ❌ OHOS_NDK_HOME not set

9.2 ❌ 链接时使用了宿主 cc 而非交叉编译器

9.3 ❌ No space left on device

9.4 ❌ Git 克隆超时或中断

9.5 ❌ hvigor 命令未找到

9.6 ❌ Tauri CLI 版本不匹配

10. 附录

10.1 完整操作流程速查

10.2 Profile 优化配置

10.3 精简 crate-type

10.4 关键技术要点速查

10.5 关键文件路径速查

10.6 参考链接

结语

所有评论(0)

温馨提示：您尚未绑定手机号

特立独行的猫a

9.1 ❌ `OHOS_NDK_HOME not set`

9.2 ❌ 链接时使用了宿主 `cc` 而非交叉编译器

9.3 ❌ `No space left on device`

9.5 ❌ `hvigor` 命令未找到