做 uni-app 鸿蒙适配的同学，迟早会撞上一个问题：HBuilderX 重新 build 之后，怎么把前端产物同步到 DevEco 原生工程，同时不覆盖你在 DevEco 里手改的 ArkTS 代码？ 本文记录了我们在实战中梳理出的三种方案、各自的适用场景，以及最终的选择。
在讨论方案之前，必须先澄清一个很容易搞混的点——HBuilderX build 出来的 app-harmony 到底是什么？
很多从 Android 转过来的同学会下意识以为：build 出来的就是一个完整的鸿蒙工程，里面有 ArkTS 代码、有 entry/、有 AppScope/、有 build-profile.json5。然后每次 rebuild 都战战兢兢，生怕把 DevEco 里手改的代码盖掉。
实际上不是。
HBuilderX build 出来的 dist/dev/app-harmony/ 里只有前端资源：
dist/dev/app-harmony/
├── pages/ # 页面 JS
├── assets/ # 静态资源
├── static/ # 静态资源
├── subPackages/ # 分包
├── TUIKit/ # 组件库产物
├── uni_modules/ # uni_modules 产物
├── app-service.js # 业务 JS 主包
├── app-renderjs.js # renderjs
├── app-wxs.js # wxs
├── app.css # 样式
├── manifest.json # 前端 manifest
└── ...
没有 ArkTS 原生代码（entry/src/main/ets/、AppScope/、chatuikit/ 等），没有 build-profile.json5、oh-package.json5、module.json5。
也就是说：重新 build 只会重新生成这套前端资源，根本不会生成/覆盖你的 ArkTS 原生代码。
真正的风险只在于——如果你「把整个 app-harmony 目录整体覆盖进 DevEco 工程」，会把前端资源连同原生壳一起盖掉。
做法：rebuild 后，只把 dist/dev/app-harmony/ 里的前端资源同步到 DevEco 原生工程的 entry/src/main/resources/resfile/apps/__UNI__XXXXXXXX/www，ArkTS 原生代码目录一律不动。
优点：
缺点：
www 目录）适用场景：
git diff 复核做法：DevEco 原生工程单独一个 git 仓库。rebuild → 同步前端产物 → git status / git diff 查看变化 → 只 stage 前端资源的变化，原生代码的 diff 保持不动。
优点：
git diff 能立刻发现异常缺点：
适用场景：
harmony-configs/做法：uni-app 官方约定了一个 harmony-configs/ 目录（位于 uni-app 项目根目录）。HBuilderX 构建时会自动把这个目录里的文件合并/覆盖到生成的鸿蒙工程中。把需要固化的原生配置（权限、签名、entry 里的固定参数等）放进去，build 时会自动合并，就不用每次在 DevEco 里手改了。
优点：
缺点：
适用场景：
这是最容易搞错的地方。方案 1 和方案 2 是必选的底线，方案 3 是锦上添花。
| 层级 | 方案 | 性质 |
|---|---|---|
| 第一层 | 方案 1：只同步前端产物 | 根本解 |
| 第二层 | 方案 2：git 独立管理 + diff 复核 | 配套纪律 |
| 第三层 | 方案 3：harmony-configs/ |
长期优化 |
方案 1 + 方案 2 是必须的底线，方案 3 看工作流决定要不要用。
只有一种核心场景会用到方案 3：HBuilderX 一键构建完整鸿蒙工程时，你手改的原生配置会被覆盖。
HBuilderX 只构建前端资源
↓
dist/dev/app-harmony/ （只有前端文件）
↓
sync-harmony.bat 同步 www 到 DevEco 原生工程
↓
原生工程 ArkTS 代码 + 原生配置 完全不动
原生配置不会被覆盖，所以不需要方案 3。
HBuilderX 一键构建完整鸿蒙工程
↓
生成完整的 ArkTS 原生工程（包含 build-profile.json5、module.json5 等）
↓
你之前在 DevEco 里手改的权限、签名、依赖 全部被覆盖 ❌
↓
必须把需要固化的配置放进 harmony-configs/
↓
HBuilderX 构建时会自动把 harmony-configs/ 的文件合并/覆盖到生成的工程 ✅
| 触发条件 | 说明 |
|---|---|
| 嫌手动同步麻烦 | 不想每次 rebuild 都跑同步脚本，希望 HBuilderX 一键出完整工程 |
| 团队多人协作 | 多人共同维护鸿蒙原生工程，需要统一的原生配置源 |
| CI/CD 自动化构建 | 需要在服务器上自动打包鸿蒙版，必须一键构建 |
| 原生工程不再独立维护 | 决定把原生工程也纳入 uni-app 项目的构建产物，不再单独 git 管理 |
只要还在用"HBuilderX 只构建前端资源 + 手动同步 www"的工作流，方案 3 就永远用不到。
dist/dev/app-harmony/scripts/sync-harmony.bat（GBK 编码，双击可跑）同步 www 到 DevEco 原生工程 E:\code_qnl\app-harmonysync-harmony.bat，只同步前端产物到 wwwE:\code_qnl\app-harmony 已独立 git 管理git status / git diff 复核harmony-configs/ 暂不迁移（当前工作流用不到）build-profile.json5 里的 signingConfigs 写死了本机绝对路径（C:\Users\admin\.ohos\config\...），换机器/加人时会失效release 产品引用的 signingConfig: "release" 实际不存在，release 包会构建失败触发条件：换机器 / 加人 → 触发签名配置剥离（模板 + .gitignore 方案）
如果你也在做 uni-app 鸿蒙适配，关于"rebuild 后怎么同步"这件事，我的建议是：
先搞清 build 产物是什么——打开 dist/dev/app-harmony/ 看一眼，里面只有前端资源，没有 ArkTS 代码。这个认知能消除 90% 的焦虑。
方案 1 + 方案 2 是必选项——写个同步脚本（bat 或 PowerShell 都行，注意编码），只同步 www；原生工程独立 git 管理，每次同步后 diff 复核。
方案 3 看工作流决定——如果你用的是 HBuilderX 一键构建完整工程，方案 3 必做；如果你用的是"只构建前端资源 + 手动同步 www"，方案 3 完全用不到，不要过度设计。
不要盲目照搬官方约定——harmony-configs/ 是 uni-app 官方约定没错，但官方约定是为官方工作流服务的。你的工作流如果不是官方那套，硬套只会增加维护成本。
痛点要记录，但不一定要立刻解决——像签名配置本机路径这种痛点，记录在案，等真正遇到"换机器/加人"的触发条件时再迁移，避免过早优化。
鸿蒙适配的技术难度不算高，但工程化细节不少。"rebuild 后怎么同步"就是其中一个典型——看起来是个操作问题，本质是个工作流选择问题。
把三种方案的关系理清，根据自己团队的工作流做选择，比盲目照搬官方约定更重要。
希望这篇对你有帮助，有问题欢迎交流。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。