如果你手上有一个 Tauri 项目，最近一周值得抬头看一眼鸿蒙。
不是那种"鸿蒙生态利好"的空泛消息，而是一件具体的事。2026 年 8 月中旬，GitHub 上 12.9 万 star 的 AI 编程配置管理器 cc-switch 完成了向鸿蒙 PC 的移植，跑通真机验证。知乎本地习惯养成应用"习惯树"也从 Windows 桌面版移植到了鸿蒙手机，全程真机验证通过。知乎更关键的是，这次用的不是民间魔改，而是 Tauri 官方仓库里的 feat/open-harmony 分支。
我去 GitHub 上核了一遍今天的状态：tauri-apps 官方账号下，tauri、wry、tao 三个核心仓库都有 feat/open-harmony 分支，cargo-mobile2 有 feat/ohos 分支；主仓库最新的 release 是 2026 年 7 月初的 v2.11.5，而鸿蒙分支正是基于这个版本。也就是说，Tauri 官方已经在认真做鸿蒙适配了，而且跟的是最新版。
但先泼半盆冷水：这些分支还没合入主线。Tauri 官方支持矩阵里，桌面 + Android + iOS 是一等公民，HarmonyOS 目前仍属于"官方在维护的分支"，生产环境要用，得自己锁定分支版本、自己承担维护成本。这不是劝退，是让你知道现在处于什么阶段——能用，但还没到"开箱即用"。
两个真实案例，移植到底要花多少钱
先说结论：前端几乎零改动，成本全在 Rust 侧和环境搭建上。
cc-switch 是目前 AI 编程工具圈人手一个的配置管理器，管 Claude Code、Codex、OpenCode 这些工具的环境变量和供应商切换，本身就是 Tauri v2 写的（React + Rust）。知乎移植者第一次用的是社区 fork，基于 tauri 2.8.5，能跑，但发现一个很典型的问题——“版本债”：上游插件早就走到 2.9/2.10，社区 fork 停在两年前，每个插件都得钉回老版本。后来改用官方 feat/open-harmony 分支重做，插件全部用最新版，一个不用降，体积还小了 10MB，全量依赖树六百多个 crate 首次编译 13 分钟一次通过。知乎
习惯树的案例更完整：从 Windows 桌面版移植到鸿蒙手机（nova 14，API 24），作者的总结是"前端 100% 不用改，Rust 后端交叉编译成 .so，套个 DevEco 工程壳就行"。知乎但别高兴太早，他强调这条路不是跑个脚本就完事——他第一次移植 cc-switch 时，光编译就炸了十几轮，真机上又炸了好几轮，前后折腾了整整一天半。知乎
这两个案例放在一起，能拼出一个比较客观的成本画像：
如果你的应用前端是标准 React/Vue，Rust 后端依赖比较纯（没有大量 C 库、没有系统级 openssl），移植的主要工作是配环境 + 跟 cargo 依赖解析器搏斗 + 补几个平台适配，熟练后大概几天量级；
如果依赖链里有原生 C 库、复杂窗口操作、系统托盘这类重桌面特性，成本会明显上浮——目前 Tauri 的一批 API 在鸿蒙段还处于缺失或降级状态，移植实录里窗口主题切换直接返回"当前平台不支持"，更新检查也不注册。知乎
五个几乎必踩的坑
把两篇移植实录里反复出现的坑提炼一下，这五个是最值得提前知道的：
localStorage 是 null。鸿蒙的 ArkWeb 在 Tauri 的自定义 scheme（tauri://localhost）下，window.localStorage 直接为空，任何读写 localStorage 的代码一碰就崩。知乎解法是写一个内存版 polyfill，而且要放在 index.html 的内联 script 里——放 JS 模块里会晚一步，因为 ES module 的 import 是提升的。代价是设置不持久化。
改了前端页面不生效。这是鸿蒙移植里最反直觉的坑：前端资产是编译期嵌进 .so 的，不是放在资源目录里。你改了前端、重新部署了 HAP，看到的还是旧页面——必须重新走一遍"vite 构建 → cargo 重建 .so → 同步 → 重新打包"的完整链路。知乎
版本必须钉死。patch 机制只替换解析器选中的精确版本，只要 crates.io 发了更高的版本，^2.11 这种写法就会绕过你的 patch 解析回官方源。知乎所以 tauri、wry 都得写成 =2.11.5、=0.56.0 这种精确版本。这也是为什么说现在移植要跟依赖解析器搏斗。
confirm/prompt 静默失效。鸿蒙桥接层没接 onJsConfirm 回调，原生 confirm() 静默返回 false——删除、重命名这类确认按钮点了没反应，不崩溃但功能失效，比崩溃还难排查。知乎
home 目录不是你想要的。鸿蒙上没有 HOME 环境变量，dirs::home_dir() 返回 None，一堆依赖它的库（比如日志插件）会往根目录写文件然后被系统拒绝。知乎应用真正可写的目录是沙箱里的 /data/storage/el2/base/files。
配套还有 Windows 上交叉编译的工具链问题（要用 gnullvm）、HAP 打包得手工装配（CLI 在 Windows 上拉不起 .bat）、签名材料恢复等一堆环境级琐事。cc-switch 的作者把踩过的 17 个坑整理成了移植手册，打算动手的人可以直接拿去当路线图。
现在想上鸿蒙，三条路怎么选
结合官方进展和社区动向，摆在 Tauri 开发者面前的其实是三条路：
路线一：等主线合入。 官方分支在维护、版本跟得紧（2.11.5 就是 crates.io 最新版），合入主线是大概率事件，只是时间未定。适合不赶窗口期、应用还在打磨期的团队。风险是鸿蒙 PC 的生态空窗期可能等不起——现在桌面应用少得可怜，早进去的应用吃的是生态位红利。
路线二：直接上官方 feat/open-harmony 分支。 这是目前两位移植者的选择，也是我的推荐项：依赖树和官方最新生态对齐，没有版本债，编译一次通过率高。代价是生产环境要锁定分支 rev，自己跟进上游更新。适合应用已经稳定、想尽快在鸿蒙 PC 上架、且团队有人能盯 Rust 依赖的。
路线三：社区 fork（基于 2.8.5）。 唯一的优点是起步早、有些现成经验帖。但版本债是结构性的——上游每发一个版本，差距就拉大一分，将来切回官方分支等于重新移植一遍。知乎除非你的项目恰好锁在 2.8.x，否则不建议。
还有一个值得留意的外围信号：8 月下旬，已经有开发者用华为仓颉语言复刻了一个"仓颉版 Tauri"（cj-tauri），在 Linux 上跑通了 Tauri 官方 hello-world。知乎思路就是给 Web 开发者铺一条进鸿蒙的低门槛路，不过作者自己也说，目前还只是方案论证阶段。
而早在今年 4 月，Eclipse 基金会已经把 Capacitor 和 Tauri 移植到了 OpenHarmony。知乎鸿蒙生态对"Web 开发者存量转化"这条路线的态度，已经相当明确了。这意味着就算你现在不动，未来一两年鸿蒙上的 Tauri 类工具只会多不会少，现在进场的先发优势也在同步贬值。
最后给个判断
值不值得现在动手？我的建议分三档：
手里有成熟 Tauri 应用、且目标是工具类（配置管理、下载器、本地笔记、AI 助手这类重后端轻窗口的应用）的——值得试。这类应用恰好是鸿蒙移植成本最低、收益最直接的类型，cc-switch 就是样板。现在鸿蒙桌面应用稀缺，上架就是占位。
应用重交互、重窗口特性（多窗口、托盘、系统深度集成）的——再等等。鸿蒙段 API 缺失面还大，现在进去一半时间花在降级适配上，性价比不高。等官方分支合入主线、插件生态的鸿蒙支持更完整再动手。
纯观望的——把三个信号放进收藏夹：feat/open-harmony 分支合入主线的 PR、Tauri 官方插件加上 OHOS 支持、鸿蒙 PC 的装机量数据。这三个里任何一个落地，都是重新评估的时机。
对了，补一句不和谐的：今年早些时候 Opencode 刚把桌面端从 Tauri 切回 Electron，理由之一正是 WebView 跨平台一致性问题。dev.to鸿蒙用的是 ArkWeb，一致性问题只会更具体。所以"Tauri 上鸿蒙"成立的前提，是你接受它现在还是一个需要自己填坑的早期生态——机会和坑是同一枚硬币的两面。
