鸿蒙 PC 构建体系详解：从 DevEco 到发布

网罗开发 （小红书、快手、视频号同名）

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

- 引言
- [一、传统 App 构建：本质是"页面打包"](#一、传统 App 构建：本质是“页面打包”)
- [二、鸿蒙 PC 为什么完全不一样](#二、鸿蒙 PC 为什么完全不一样)
- [三、DevEco 到底在做什么？](#三、DevEco 到底在做什么？)
- [四、鸿蒙构建的真正核心：Module 化](#四、鸿蒙构建的真正核心：Module 化)
- 五、HAP：真正的运行单元
- [六、HAR：为什么它不是普通 Library](#六、HAR：为什么它不是普通 Library)
- 七、真正的大项目：一定是"多层构建体系"
- - [1、Foundation Layer](#1、Foundation Layer)
  - [2、Runtime Layer](#2、Runtime Layer)
  - [3、Domain Layer](#3、Domain Layer)
  - [4、Workspace Layer](#4、Workspace Layer)
- 八、为什么很多鸿蒙项目后期构建越来越慢
- 九、真正稳定的构建体系：领域隔离
- [十、鸿蒙 PC 为什么天然适合"动态化"](#十、鸿蒙 PC 为什么天然适合“动态化”)
- [十一、真正复杂的：不是 UI，而是 Runtime](#十一、真正复杂的：不是 UI，而是 Runtime)
- 十二、发布阶段真正发生了什么
- - 1、能力注册
  - [2、Runtime 绑定](#2、Runtime 绑定)
  - 3、设备能力适配
  - 4、安全与签名
- [十三、为什么鸿蒙 PC 构建越来越像"系统工程"](#十三、为什么鸿蒙 PC 构建越来越像“系统工程”)
- 十四、真正的未来：构建"状态运行系统"
- 十五、总结

引言

很多人第一次做鸿蒙 PC 应用时，会下意识觉得：

text 复制代码

不就是"写完代码 → 点发布"吗？

因为在很多移动开发场景里：

text 复制代码

构建
≈
打包

但真正开始做鸿蒙 PC 项目之后，很快就会发现：

多模块越来越复杂
HAP / HAR 开始混乱
多设备构建越来越重
Debug 与 Release 行为不一致
DevEco 编译越来越慢
多窗口资源开始失控
AI / 分布式模块越来越难管理

最后团队会慢慢意识到：

鸿蒙 PC 的"构建体系"，其实已经不是简单打包。

而是：

一套完整的"系统运行组织结构"。

因为鸿蒙 PC 真正复杂的地方：

text 复制代码

不是页面
而是状态系统 + 多模块协同

所以：

text 复制代码

构建体系
本质上就是系统结构

一、传统 App 构建：本质是"页面打包"

过去很多移动应用：

text 复制代码

页面
↓
资源
↓
安装包

本质就是：

text 复制代码

静态资源打包

所以：

APK
IPA
Web Bundle

核心都围绕：

text 复制代码

页面与资源

组织。

二、鸿蒙 PC 为什么完全不一样

因为鸿蒙 PC 真正运行的：

text 复制代码

不是"页面"
而是"状态系统"

它天然具备：

多窗口
Workspace
分布式状态
动态能力
Task Runtime
AI Runtime
跨设备协同

这些意味着：

构建目标不再只是"生成页面"。

而是：

text 复制代码

组织系统运行结构

三、DevEco 到底在做什么？

很多人把 DevEco Studio 理解成：

text 复制代码

一个 IDE

其实不是，它真正核心更像：

text 复制代码

HarmonyOS Runtime Organizer

也就是说：

DevEco 不只是"编译代码"。

而是在组织：

Module
Ability
State
Resource
Runtime
Device Capability

四、鸿蒙构建的真正核心：Module 化

很多人第一次接触鸿蒙工程时，会看到：

text 复制代码

entry
feature
library
har
hap

然后开始迷糊，其实核心思想非常简单：

鸿蒙不是"页面组织"。

而是：

text 复制代码

能力组织

五、HAP：真正的运行单元

很多人误以为：

text 复制代码

HAP ≈ APK

其实差异很大，在鸿蒙里：

text 复制代码

HAP 更像"动态能力容器"

它不只是：

页面
资源

还包括：

Ability
Service
状态能力
分布式能力

也就是说：

HAP 本质是 Runtime Module。

六、HAR：为什么它不是普通 Library

很多团队会把：

text 复制代码

HAR

当成：

text 复制代码

工具库

但真正大型鸿蒙项目里，HAR 更像：

text 复制代码

领域能力模块

例如：

text 复制代码

order.har
message.har
workspace.har
ai.har

这里面不只是 UI，还包括：

Store
Task
Repository
Runtime
Focus Logic

所以：

text 复制代码

HAR 本质是领域系统单元

七、真正的大项目：一定是"多层构建体系"

成熟鸿蒙 PC 项目通常会变成：

text 复制代码

App
 ↓
Workspace Layer
 ↓
Domain Layer
 ↓
Runtime Layer
 ↓
Foundation Layer

1、Foundation Layer

负责：

网络
日志
存储
分布式能力
AI Runtime

例如：

text 复制代码

foundation.har

2、Runtime Layer

负责：

Task 调度
Focus
Workspace
生命周期

例如：

text 复制代码

runtime.har

3、Domain Layer

负责：

订单
用户
消息
AI Agent

例如：

text 复制代码

order.har
user.har

4、Workspace Layer

负责：

多窗口
布局
状态投影

例如：

text 复制代码

workspace.har

八、为什么很多鸿蒙项目后期构建越来越慢

因为：

text 复制代码

模块边界失控

很多项目：

所有模块互相依赖
Store 到处引用
System 横向耦合
HAR 无限膨胀

最后：

text 复制代码

一次修改
全量重编译

九、真正稳定的构建体系：领域隔离

后来很多成熟团队都会慢慢演化成：

text 复制代码

领域独立构建

例如：

text 复制代码

user.har

绝不能依赖：

text 复制代码

order.har

而应该：

text 复制代码

通过 Runtime 通信

否则：

text 复制代码

整个工程会越来越重

十、鸿蒙 PC 为什么天然适合"动态化"

这一点很多人忽略，传统 App：

text 复制代码

页面编译完成
↓
功能固定

但鸿蒙：

text 复制代码

能力可动态加载

因为：

text 复制代码

系统核心是 Runtime

不是：

text 复制代码

静态页面

所以未来：

AI Plugin
动态 Workspace
Task Module
Agent Skill

都会越来越重要。

十一、真正复杂的：不是 UI，而是 Runtime

很多人后期会发现：

text 复制代码

UI 根本不是最难的

真正复杂的是：

Task Runtime
状态同步
分布式状态
多窗口生命周期
AI Runtime

所以：

text 复制代码

构建体系最终会越来越像"操作系统"

而不是：

text 复制代码

页面工程

十二、发布阶段真正发生了什么

很多人觉得：

text 复制代码

Release
=
生成安装包

其实鸿蒙发布真正做的是：

1、能力注册

例如：

Ability
Service
分布式能力

2、Runtime 绑定

例如：

Workspace Runtime
Focus Runtime
Task Runtime

3、设备能力适配

例如：

PC
手机
平板
分布式设备

4、安全与签名

包括：

权限
分布式身份
设备可信关系

十三、为什么鸿蒙 PC 构建越来越像"系统工程"

因为：

text 复制代码

应用已经开始"系统化"

传统 App：

text 复制代码

页面 + 接口

而鸿蒙 PC：

text 复制代码

Workspace + Runtime + State Flow

复杂度已经完全不同。

十四、真正的未来：构建"状态运行系统"

未来大型鸿蒙 PC 项目，真正核心会慢慢变成：

text 复制代码

Task Runtime
Workspace Runtime
AI Runtime
Distributed Runtime

而不是：

text 复制代码

页面打包

这也是为什么：

鸿蒙 PC 后期越来越不像"传统 App"。

而越来越像：

text 复制代码

一个持续运行的状态系统

十五、总结

如果一句话总结鸿蒙 PC 构建体系：

从 DevEco 到发布，本质上是在组织"系统运行结构"。

很多人以为：

text 复制代码

构建 = 编译代码

其实真正发生的是：

text 复制代码

状态能力组织
Runtime 装配
Workspace 构建

这已经不是：

text 复制代码

传统页面工程

而是：

text 复制代码

系统级 Runtime 工程

真正成熟的鸿蒙 PC 构建体系，一定具备：

Runtime 分层
Workspace 中心化
HAR 领域隔离
Task Runtime 独立
状态边界清晰
分布式能力解耦

因为：

text 复制代码

未来真正复杂的
不是"页面"
而是"持续运行的状态系统"

最终你会发现：

DevEco 不只是一个 IDE。

而是：

鸿蒙状态系统的"运行时装配中心"。