HarmonyOS NEXT 应用架构设计：别太早沉迷“功能做出来了”

这两年看不少 HarmonyOS NEXT 项目，有个感受越来越明显：很多团队并不是卡在“不会写”，而是卡在“写得太顺”。页面能出来，接口能通，动画也能跑，一切看上去都很顺利。真正的麻烦往往出现在后面。需求开始反复调整，页面之间要共享状态，设备能力接入越来越多，原本图省事写下去的代码，突然成了谁都不想碰的地方。

这种问题并不新鲜，只是在鸿蒙项目里更容易被放大。生态还在快速演进，团队经验也常常不够稳定，于是很多开发动作会不自觉地偏向“先把它做出来”。这当然没错，但如果一个项目长期停留在这个思路里，后续的成本会比想象中来得更早。

文档解决的是“能不能做”，不是“该怎么做”

刚入手 HarmonyOS NEXT 时，大家对官方资料的依赖都很强，这很正常。像华为开发者联盟的 HarmonyOS 官方文档 基本就是每天都会打开的入口，查组件、看能力限制、确认工程方式，很多问题都要回到这里找答案。

但文档的作用，更多是告诉你一件事“可以怎样实现”，而不是“你的项目应该怎样组织”。这两者差别不小。官方示例为了让人快速理解，通常会刻意压缩上下文，省略掉大量真实业务中才会出现的复杂性。它不会替你处理多人协作下的命名混乱，不会替你决定状态该放在哪一层，也不会提醒你一个页面承担过多职责后，后面几次需求迭代会有多难受。

很多开发者在早期最容易犯的错，就是把“示例可运行”误认为“结构可扩展”。前者只是起点，后者才决定项目能不能走远。

真正拉开差距的，是工程边界感

我一直觉得，HarmonyOS 项目中最容易被低估的能力，不是设备能力接得多快，而是边界划分做得够不够清楚。一个页面到底只负责展示和交互，还是顺手把请求、缓存、埋点、弹窗、鉴权全都塞进去，这件事看上去只是写法选择，实际上决定了后面的维护体验。

很多项目早期都喜欢“大页面”模式，因为快，肉眼可见地快。文件集中，逻辑直接，出效果也立刻。但这种快有点像透支。需求一多，页面就开始变重，状态之间互相牵扯，改一个列表筛选可能影响详情页，补一个异常分支又把原来的交互节奏打乱。到这个阶段，团队消耗的不是编码时间，而是理解上下文的时间。

Google 在自己的 应用架构指南 里一直强调 UI、状态和数据职责要分离。它讲的是 Android，但这类原则放到 HarmonyOS 上同样成立。因为不管技术栈怎么变，软件一旦进入多人维护和持续迭代阶段，最怕的都是职责混在一起。平台不同，问题本质却差不多。

如果一定要把经验说得更直接一点，那就是页面层应该尽量只处理页面问题，业务状态最好有更清晰的归属，网络、存储、埋点和设备能力封装也要有稳定出口。你不一定要追求多复杂的分层，也没必要一上来就搬一整套“大架构”，但至少要避免把所有职责都堆进一个入口文件里。真正让项目失控的，常常不是某个接口难用，而是所有东西都没有边界。

比起“写得快”，更重要的是“留有余地”

做技术项目久了会发现，真正可靠的工程习惯常常带着一点克制。不是每个功能都要在首屏一次性装满，不是每段逻辑都该就近写在页面里，也不是每个需求都值得用最短路径硬接上去。很多经验其实都指向同一件事：给后续修改留空间。

比如首屏阶段，优先完成关键路径就够了，非核心任务没必要抢着执行。再比如状态管理，越早明确来源和归属，后面越不容易陷入“这里也能改，那里也在改”的混乱。还有异常处理，很多团队喜欢把它当收尾工作，觉得功能通了再补就好，但用户真正感知产品是否成熟，往往不是看正常路径有多顺，而是看失败时有没有体面地收住。

这也是我现在看 HarmonyOS 项目最在意的一点：有没有节制。不是做得少，而是不乱做。能在一开始就克制住那种“先堆上去再说”的冲动，后面通常会轻松很多。

结尾

HarmonyOS NEXT 还在持续发展，能力会更新，范式也会变化，但有些事情不会变。项目能不能做稳，不只看你会不会用组件、能不能接能力，更看你是否愿意在早期就认真处理结构、职责和复杂度。

功能做出来当然重要，但那只是开始。真正决定项目质量的，往往是那些当下看起来有点“慢”、后来却不断替你省事的选择。写鸿蒙应用也是一样。别太早沉迷“已经跑起来了”，更值得在意的是，它下个月是不是还改得动。