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

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

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

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

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

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

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

引言

很多人第一次做鸿蒙电商类 App 时，都会觉得：

登录很简单
订单很常规
支付调个 SDK 就行

于是项目初期通常会这样写：

页面调接口
接口返回数据
UI 自动刷新

刚开始功能确实能跑。但项目一旦变大，很快就会进入一种熟悉的状态：

登录状态到处都是
订单状态越来越乱
支付流程越来越不可控

最后你会发现：

• 页面越来越耦合
• 状态越来越混乱
• AI 接入越来越困难
• 分布式同步越来越危险

很多鸿蒙项目后期崩掉，并不是因为：

功能太复杂

而是：

核心业务系统没有真正拆清楚。

这也是为什么：

登录
订单
支付

永远是中大型 App 最核心的架构问题。

一、为什么“登录 / 订单 / 支付”最容易写崩

因为这三个系统天然具备：

• 全局状态
• 多流程协同
• 高并发
• 分布式同步
• AI 调度
• 生命周期复杂

它们本质上都不是：

页面功能

而是：

系统级能力

一个典型错误

很多项目会这样：

@State user: User
@State order: Order
@State paying: boolean

然后：

页面直接操作所有业务

后面一定会出现：

• 页面互相覆盖状态
• 支付回调状态错乱
• 登录失效后订单异常
• AI 调度导致流程冲突

最后整个系统会变成：

状态泥潭

二、真正稳定的鸿蒙业务架构

推荐一个非常稳定的结构：

UI
 ↓
Store
 ↓
Task
 ↓
System
 ↓
Repository

这是未来 AI 鸿蒙 App 非常核心的结构。

每层职责

UI 只负责：

展示
交互

Store 负责：

状态管理

Task 负责：

流程编排

System 负责：

无状态能力

Repository 负责：

数据访问

三、登录系统到底应该怎么拆

很多人会把登录写成：

login() {
  api.login()
}

但真正中大型项目里：

登录 ≠ 一个接口

而是：

• Token 管理
• Session 生命周期
• 多设备同步
• 权限刷新
• AI 权限控制
• 分布式登录态

正确结构

auth/
 ├── store/
 ├── task/
 ├── system/
 ├── repository/
 └── ui/

四、登录 Store

Store 负责：

登录状态
用户信息
Token

示例

class AuthStore {

  user: User | null = null

  token: string = ""

  logged: boolean = false

}

这里有一个关键原则

只有 Store 能持有登录状态。

页面不能：

偷偷缓存 user

System 也不能：

内部保存 token

否则后面一定：

状态失控

五、登录 Task 才是真正核心

因为登录本质是：

一个任务流

例如：

• 获取验证码
• 登录
• 拉取用户信息
• 初始化权限
• 同步设备状态
• 初始化 AI Session

示例

class LoginTask {

  async run(phone: string, code: string) {

    const token =
      await authSystem.login(phone, code)

    authStore.token = token

    const user =
      await authSystem.profile()

    authStore.user = user

  }

}

注意一个核心点

Task：

负责流程

Store：

负责状态

两者必须彻底分离。

六、订单系统为什么最容易爆炸

因为订单天然具备：

复杂状态机

例如：

待支付
已支付
待发货
运输中
已完成
已取消

很多项目的问题：

页面直接改订单状态

例如：

order.status = "paid"

这会非常危险。

正确模型

订单状态必须统一走：

OrderTask

示例

class PayOrderTask {

  async run(orderId: string) {

    await paySystem.pay(orderId)

    orderStore.updateStatus(
      orderId,
      "paid"
    )

  }

}

这里：

Task 控制流程
Store 管理状态

七、支付系统为什么不能“页面化”

很多人第一次写支付：

Button("支付")
  .onClick(() => {
    pay()
  })

问题在于：

支付不是页面行为

而是：

系统级事务

因为支付会涉及：

• 回调
• 重试
• 中断恢复
• 多设备同步
• 风险校验
• AI 自动支付

正确结构

PayTask
   ↓
PaySystem
   ↓
OrderStore

八、支付为什么特别适合 Task 架构

因为支付天然是：

长任务

例如：

创建支付单
 ↓
调起 SDK
 ↓
等待结果
 ↓
校验签名
 ↓
更新订单

这本质就是：

任务流

示例

class PayTask {

  async run(orderId: string) {

    const payInfo =
      await paySystem.create(orderId)

    const result =
      await paySystem.invoke(payInfo)

    if (result.success) {

      orderStore.finish(orderId)

    }

  }

}

九、为什么 AI 会放大这些系统的问题

传统 App：

用户一步一步操作

AI App：

AI 自动完成整条流程

例如：

await agent.run("帮我购买这本书")

AI 可能：

• 自动登录
• 自动创建订单
• 自动支付
• 自动同步设备

如果没有：

Task 边界
State 边界

整个系统一定：

彻底失控

十、鸿蒙为什么更需要“Task + Store”

因为鸿蒙天然具备：

• 分布式
• 多设备
• 实时同步
• AI 调度
• Task 流转

这些能力本质上都依赖：

稳定状态流

一个非常关键的认知

很多人以为：

鸿蒙核心是 UI

其实真正核心是：

Task Flow + State Flow。

因为：

未来页面会越来越弱
任务会越来越强

十一、推荐一个完整结构

app/
 ├── auth/
 │    ├── store/
 │    ├── task/
 │    ├── system/
 │    └── repository/
 │
 ├── order/
 │    ├── store/
 │    ├── task/
 │    ├── system/
 │    └── repository/
 │
 ├── pay/
 │    ├── store/
 │    ├── task/
 │    ├── system/
 │    └── repository/

每个领域独立

例如：

auth 不依赖 order
pay 不直接操作 UI

整个系统会稳定很多。

十二、真正优秀的鸿蒙业务系统长什么样

不是：

页面很多
功能很多

而是：

结构极其清晰

通常具备：

• Store 中心化
• Task 驱动
• 无状态 System
• Repository 隔离
• 分布式状态同步
• AI 调度边界

这些东西：

决定项目后期还能不能继续迭代。

十三、总结

如果用一句话总结：

登录 / 订单 / 支付，本质上都是“任务 + 状态”系统。

登录：

状态系统

订单：

状态机系统

支付：

长任务系统

而未来鸿蒙 App 的核心趋势一定会越来越明显：

页面外围化
Task 中心化
State 核心化

很多鸿蒙项目后期越来越难维护，并不是因为：

• 接口太多
• 页面太复杂
• AI 太难接

真正的问题其实只有一个：

核心业务系统没有架构化。

记住一句话：

登录不是页面
订单不是页面
支付也不是页面

它们本质上都是：

长期运行的系统能力。

当你真正建立：

• Task Flow
• State Flow
• Store 中心化
• 无状态 System
• 领域拆分

你会明显感觉到：

整个鸿蒙 App 开始真正稳定了