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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

引言

几乎每个鸿蒙项目，都会经历一个看起来很“安心”的时刻：

功能做完了、流程能走通、真机也不崩。

甚至测试同事都会说一句：

“已经可以提测了。”

表面上看，一切都在向上线推进。但真正做过完整生命周期的人都知道——

项目最容易死掉的，不是做不出来，而是刚好能跑的时候。

因为从这一刻开始，所有真正的工程问题，才刚刚露头。

第一种错觉：能跑 = 架构正确

很多团队在功能跑通后，会自然产生一种判断：

既然现在没问题，说明架构大体是对的。

于是接下来发生的事情通常是：

• 不再重构核心结构
• 所有问题都用补丁解决
• 新需求直接叠在旧代码上

短期看效率很高，长期看却是在做一件危险的事：

把“偶然可用”，当成“结构正确”。

真正的架构问题有一个特点：

在规模变大之前，几乎看不见。

典型代码形态：功能能跑，但结构不可持续

// 页面直接持有业务逻辑
@State userInfo: User | null = null

async aboutToAppear() {
  this.userInfo = await UserApi.query()
}

// 新需求继续叠加
async refreshVip() {
  const vip = await VipApi.query()
  this.userInfo!.vip = vip
}

这类代码在早期完全正常，但它隐藏的问题是：

页面 = 状态中心 = 业务入口

当页面一多，复杂度会指数级上升。

第二种错觉：不卡 = 没问题

鸿蒙 App 在早期阶段通常都很流畅，原因很简单：

• 页面少
• 状态简单
• 任务单一
• 数据量极小

这时候的“流畅”，本质上只是：

系统还没被真正使用。

一旦进入真实场景：

• 多窗口并行
• 长时间驻留
• 后台恢复
• 复杂协作链路

你会发现之前的流畅感迅速消失，但又说不上是哪一行代码出了问题。

因为真正的瓶颈从来不是：

某一帧慢了。

而是：

整体结构开始互相拉扯。

一个常见但隐蔽的结构拉扯

// A 页面监听全局状态
AppStorage.setOrCreate('cartCount', 0)

// B 页面也在改
AppStorage.set('cartCount', newCount)

// C 页面又依赖这个值触发网络请求
@StorageLink('cartCount') cartCount: number = 0

单看每一处都没问题，但组合在一起就是：

状态耦合链条失控。

第三种错觉：问题可以以后再说

“先上线，再优化”，几乎是所有项目都会出现的一句话。

这句话最危险的地方不在于节奏，而在于它默认了一件事：

后期优化是可行的。

但现实往往相反，当项目进入中后期：

• 代码耦合已经形成
• 状态路径无法梳理
• 生命周期到处穿透
• 改动开始牵一发而动全身

这时你会突然意识到：

很多问题，其实已经没有优化空间， 只剩推倒重来。

而真正致命的是——大多数项目走不到“推倒重来”。

为什么后期几乎无法优化

// 多处直接依赖同一工具类
UserManager.getUser()
OrderManager.getOrders()
DeviceManager.getDevice()

这些 Manager 在早期很好用，但中后期会变成：

全局耦合入口。

一旦修改内部逻辑：

全项目震动。

真正的分水岭，从这里才开始

一个鸿蒙 App 能不能活下来，从来不是看：

• 第一版做得多快
• 页面做得多漂亮
• 功能堆得多完整

真正决定生死的，是在“刚好能跑”之后，团队做出的那一次选择：

继续堆功能还是停下来重建结构

这一步看起来只是节奏选择，本质上却是在决定：

项目未来三年的上限。

两种选择的代码走向

继续堆功能：

// 新需求继续写在旧页面
async addNewFeature() {
  const data = await NewApi.query()
  this.list.push(data)
}

停下来重建结构：

class FeatureTask {
  async load() { /* 独立任务 */ }
}

// 页面只订阅任务结果
aboutToAppear() {
  this.vm.bind(FeatureTaskManager.current())
}

差别不在代码多少，而在：

是否开始“任务化”。

为什么这个阶段最危险

因为它同时具备三种特征：

一、问题还不痛

系统还能跑，所以没有足够动力去改。

// 虽然耦合严重，但功能正常
if (this.user && this.order) {
  this.render()
}

二、结构已经固化

越往后改动成本越高。

// 被几十个页面依赖的公共方法
export function formatPrice(p: number) { ... }

当这种函数进入“到处调用”阶段：

重构成本趋近无限。

三、时间窗口正在关闭

等真正崩的时候，通常已经来不及重构。

// 紧急修复补丁
try {
  doSomething()
} catch {}

补丁越多，系统熵越高。

成熟团队在这里会做一件“反直觉”的事

不是加人赶进度，也不是继续扩需求。

而是突然慢下来，开始做三件看似“不产出”的事：

• 统一状态模型
• 重建任务边界
• 拆开能力耦合

这些工作短期几乎没有可见收益，却决定了一件最重要的事：

这个 App，未来还能不能继续长大。

一个简单但关键的结构变化

// 过去：页面持有状态
@State orders: Order[] = []

// 现在：任务持有状态
class OrderTaskStore {
  orders: Order[] = []
}

状态归属改变 = 架构真正开始进化。

你很少看到成功项目死在早期

真正失败的项目，大多死在一个非常相似的时间点：

第一版上线前后。

因为那时：

• 技术债刚刚形成
• 复杂度刚刚开始爬升
• 但一切还看起来“没那么严重”

于是所有人都会下意识选择：

先往前走一步再说。

可很多项目，就是在这“一步一步”里，慢慢失去回头路。

总结

鸿蒙 App 开发里最危险的阶段，从来不是：

做不出来的时候。

而恰恰是：

一切都看起来已经可以运行的时候。

因为真正决定长期生死的那些问题——

• 架构
• 状态
• 任务
• 协作

都不会在早期暴露，却会在未来某一天同时爆发。