子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多鸿蒙项目，在走到中后期时，都会出现一种非常微妙的状态：

功能很全，界面也稳定，线上问题不多，但团队越来越不敢动代码。

不是改不了，而是——改之前必须先害怕一下。

小需求要评估半天，修 Bug 要全链路回归，一次改动可能影响三个看似无关的模块。

表面上，这是“复杂度上来了”。但更真实的原因是：

结构已经悄悄固化。

而你可能还没意识到。

一、最危险的阶段：系统“刚好能用”

真正容易出问题的，从来不是项目初期。

初期的问题反而最清晰：

• 页面还没搭完
• 状态模型混乱
• 生命周期到处是坑

这些问题肉眼可见，也最容易下决心重构。

真正危险的，是项目进入一种看似健康的阶段：

功能齐了、Bug 不多 、性能还能接受 、上线节奏稳定

团队会下意识认为：

系统已经成熟。

但工程经验告诉我们：

“刚好能用”，往往是结构失控的起点。

因为从这一刻开始——你停止了对结构的主动修正。

二、难改的本质，从来不是代码多

很多人第一反应是：

代码太多，所以难改。

但真正让系统变得难以修改的，通常不是“数量”，而是三种更深层的变化。

1、状态开始失去唯一来源

项目早期，状态通常还比较集中：

class AppState {
  user?: User
  currentPage?: string
}

随着功能增长，状态会被不断“就近放置”：

• 页面里一份缓存
• 组件里一份局部状态
• 服务层再维护一份副本

短期看是效率优化，长期却会变成：

系统开始出现多个“真相”。

于是你会看到典型现象：

• UI 显示的是旧数据
• 刷新一次突然跳变
• 不同页面看到的状态不一致

当状态不再唯一时，每一次修改都会变成一次赌博。

2、任务流程被页面切碎

在移动时代，一个非常自然的等式是：

页面 = 功能

但在鸿蒙，尤其进入 PC / 多窗口 / 跨 Ability 之后：

任务 > 页面

如果核心流程仍然散落在多个页面回调中：

onClickNext()
onPageShow()
onResultBack()

那系统就会慢慢出现一种结构性问题：

流程没有中心。

表现就是：

• 恢复流程极其困难
• 多窗口下状态错乱
• 一次需求要改三个页面

当任务没有独立存在时，页面越多，系统就越难动。

3、能力边界开始消失

项目早期，为了效率，最常见的写法是直接调用：

A 调 B  
B 顺便改全局状态  
C 再去触发 UI 更新

这种写法在前期非常高效，甚至让人产生一种错觉：

结构很简单。

但随着链路增长，系统会进入一种典型状态：

所有模块都能工作，但没有任何模块是独立的。

这时再改一个点，就可能牵动整条隐形依赖链。

于是团队开始说那句熟悉的话：

“这块先别动，风险太大。”

当这种话越来越多时，系统其实已经进入冻结前夜。

三、为什么这种失控很难被及时发现

因为它不像 Bug 那样明显。

结构失控有三个典型特征：

1、短期完全不影响上线

• 功能还能继续加
• 需求还能按时交
• 用户几乎无感

于是问题被不断推迟。

2、每一次“临时修补”都在加深问题

// 先这样兜一下
if (!data) {
  data = cache.get()
}

这种代码看似解决问题，实际上在制造新的状态分叉。

3、团队会逐渐习惯这种不确定性

当大家开始默认：

改动一定会带来副作用

说明系统已经从工程问题，变成了结构问题。

四、真正的转折，不是继续优化，而是重新看结构

当鸿蒙 App 进入“越来越难改”的阶段，继续做这些事情通常不会真正解决问题：

• 再做一次性能优化
• 再补一层缓存
• 再加几条防御判断

因为这些都发生在：

结构之内。

而真正需要改变的，是：

结构本身。

也就是你前面那条主线已经走到的地方——第一次架构重建。

五、一个很残酷但真实的规律

在长期演进的应用里，几乎都会出现两种结局：

没有重建的项目

• 两三年后进入冻结
• 只能小修小补
• 最终被整体替换

完成第一次重建的项目

短期会经历：

• 开发节奏变慢
• 重构成本上升
• 外界看不到“成果”

但长期会获得一种更重要的能力：

系统重新变得可以修改。

而这，才是真正的生命线。

六、最容易被忽略的一点

很多人以为：

难改，是因为系统太复杂。

但更准确的说法其实是：

难改，是因为系统失去了“可演化结构”。

复杂本身不是问题，不可控的复杂才是。

总结

看似完整的鸿蒙 App，之所以会越来越难改，往往不是因为技术不够强，也不是因为代码写得不够好。

真正的原因只有一个：

系统在悄悄固化，而你还以为它在健康生长。

而当团队第一次真正停下来，重新面对结构本身时——

那一刻，才是鸿蒙 App 真正的转折开始。