8.9
深览指数
科技人人都是产品经理·nutpi··AI 生成
在鸿蒙 PC 上用 Rust + Tauri 开发鸿蒙应用：从零到真机跑通
本文是一篇在 HarmonyOS 7.0 PC 上使用 Tauri 的 OpenHarmony 分支，将 Rust 应用跑进原生窗口的完整实操记录。作者详细记录了从环境准备、工程搭建、Rust 编译与链接（含处理 musl libc、缺失 C 工具链、二进制强制自签名等平台差异），到 HAP 构建、签名安装及调试的每一步，并给出了所有命令的报错原文、修复方案和实测耗时。文章核心贡献在于：系统梳理了 Tauri 在鸿蒙 PC 上因用户态差异（musl / 强制签名 / 文件系统 EINTR）带来的四个大坑及其绕过方案，并提供了一个完整的零依赖工程结构。适合需要在鸿蒙 PC 上进行原生跨平台开发、或对 Tauri 在非标准 Linux 平台移植感兴趣的资深开发者阅读。原文 ↗
核心观点
- ▍在 HarmonyOS PC 上使用 Tauri 开发应用是可行的，但过程充满平台差异导致的坑，需要手工绕开许多标准 Linux 开发的假设。
- ▍鸿蒙 PC 上的 Tauri 应用本质是一个带原生 webview 的鸿蒙应用，Rust 代码作为动态库（.so）通过 N-API 被加载进 ArkTS 壳的进程。
- 01最终应用形态为：外层 ArkTS 壳继承 @ohos-rs/ability 的 NativeAbility，内层 Rust（tauri + wry）起 ArkWeb webview，前端使用零依赖静态页面通过 window.__TAURI__ 直连 Rust 命令。
- 02鸿蒙 PC 与标准 Linux 的四大硬性差异：1) 用户态为 musl，目标三元组是 aarch64-unknown-linux-ohos；2) 系统无 C 工具链（cc/gcc/clang）；3) 二进制文件必须自签名，否则内核以 'Operation not permitted'（126）拒绝执行；4) 文件系统偶发 EINTR，导致 cargo 的 git checkout 失败。
- 03文章提供了绕过 cargo 因 EINTR 导致 checkout 失败的方法：从错误信息提取出问题的目录，用 git archive + tar 手工铺好文件，并补上 .cargo-ok 标记。
- 04文章提供了一个自制的 '链接器包装器'（ohos-cc-sign），代理调用 SDK 自带的 clang，并在链接后自动摘除占位段、完成自签名，解决了无 cc 和二进制强制签名的双问题。
- 05应用前端的 'Failed to request tauri://localhost/' 报错可能由三个根因导致：构建被判为 dev 构建（缺 custom-protocol 特性）、运行时配置文件（gen/ohos/assets/tauri.conf.json）未同步、窗口未显式指定 url。
- 06最终 HAP 构建必须使用华为 AGC（AppGallery Connect）签发的签名材料，OpenHarmony SDK 自带的根证书在 HarmonyOS 设备上不被信任，会报 9568257 错误。
反方 / 局限
- — 当前 Tauri 的鸿蒙支持依赖于开源的 feature 分支和固定 rev 的 openharmony-ability 库，与上游主线存在漂移风险，不支持简单的 cargo update 升级。
- — 构建流程高度手工化，绕过了 tauri-cli，但需要开发者理解框架底层细节（如环境变量注入、配置同步）。整套流程对新手不够友好，首次全量构建约需2分钟。
- — 前端依赖生态受限：零依赖静态页面规避了打包器问题，但意味着无法直接使用 React/Vue 等主流前端框架。
- — 设备绑定签名与调试 profile 限制，换设备需重新申请，且缺乏官方自动化流程，对团队协作是潜在瓶颈。
TauriRustOpenHarmonyArkTSArkWebN-APImuslEINTRAGC (AppGallery Connect)HarmonyOSdevecoclihvigorhdcricherfuopenharmony-abilityllvm-objcopybinary-sign-toolhap-sign-toolHUAWEI MateBook Pro (HAD-W32)HarmonyOS 7.0
103 分钟 · 4 卡片 · 12 资料
读原文 →