鸿蒙 App 的登录 / 订单 / 支付系统拆解

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

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

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

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

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

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 引言
- [一、为什么"登录 / 订单 / 支付"最容易写崩](#一、为什么“登录 / 订单 / 支付”最容易写崩)
- - 一个典型错误
- 二、真正稳定的鸿蒙业务架构
- - 每层职责
- 三、登录系统到底应该怎么拆
- - 正确结构
- [四、登录 Store](#四、登录 Store)
- - 示例
  - 这里有一个关键原则
- [五、登录 Task 才是真正核心](#五、登录 Task 才是真正核心)
- - 示例
  - 注意一个核心点
- 六、订单系统为什么最容易爆炸
- - 正确模型
  - 示例
- 七、支付系统为什么不能"页面化"
- - 正确结构
- [八、支付为什么特别适合 Task 架构](#八、支付为什么特别适合 Task 架构)
- - 示例
- [九、为什么 AI 会放大这些系统的问题](#九、为什么 AI 会放大这些系统的问题)
- [十、鸿蒙为什么更需要"Task + Store"](#十、鸿蒙为什么更需要“Task + Store”)
- - 一个非常关键的认知
- 十一、推荐一个完整结构
- - 每个领域独立
- 十二、真正优秀的鸿蒙业务系统长什么样
- 十三、总结

引言

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

text 复制代码

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

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

text 复制代码

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

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

text 复制代码

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

最后你会发现：

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

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

text 复制代码

功能太复杂

而是：

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

这也是为什么：

text 复制代码

登录
订单
支付

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

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

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

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

它们本质上都不是：

text 复制代码

页面功能

而是：

text 复制代码

系统级能力

一个典型错误

很多项目会这样：

ts 复制代码

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

然后：

text 复制代码

页面直接操作所有业务

后面一定会出现：

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

最后整个系统会变成：

text 复制代码

状态泥潭

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

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

text 复制代码

UI
 ↓
Store
 ↓
Task
 ↓
System
 ↓
Repository

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

每层职责

UI 只负责：

text 复制代码

展示
交互

Store 负责：

text 复制代码

状态管理

Task 负责：

text 复制代码

流程编排

System 负责：

text 复制代码

无状态能力

Repository 负责：

text 复制代码

数据访问

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

很多人会把登录写成：

ts 复制代码

login() {
  api.login()
}

但真正中大型项目里：

text 复制代码

登录 ≠ 一个接口

而是：

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

正确结构

text 复制代码

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

四、登录 Store

Store 负责：

text 复制代码

登录状态
用户信息
Token

示例

ts 复制代码

class AuthStore {

  user: User | null = null

  token: string = ""

  logged: boolean = false

}

这里有一个关键原则

只有 Store 能持有登录状态。

页面不能：

text 复制代码

偷偷缓存 user

System 也不能：

text 复制代码

内部保存 token

否则后面一定：

text 复制代码

状态失控

五、登录 Task 才是真正核心

因为登录本质是：

text 复制代码

一个任务流

例如：

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

示例

ts 复制代码

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：

text 复制代码

负责流程

Store：

text 复制代码

负责状态

两者必须彻底分离。

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

因为订单天然具备：

text 复制代码

复杂状态机

例如：

text 复制代码

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

很多项目的问题：

text 复制代码

页面直接改订单状态

例如：

ts 复制代码

order.status = "paid"

这会非常危险。

正确模型

订单状态必须统一走：

text 复制代码

OrderTask

示例

ts 复制代码

class PayOrderTask {

  async run(orderId: string) {

    await paySystem.pay(orderId)

    orderStore.updateStatus(
      orderId,
      "paid"
    )

  }

}

这里：

text 复制代码

Task 控制流程
Store 管理状态

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

很多人第一次写支付：

ts 复制代码

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

问题在于：

text 复制代码

支付不是页面行为

而是：

text 复制代码

系统级事务

因为支付会涉及：

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

正确结构

text 复制代码

PayTask
   ↓
PaySystem
   ↓
OrderStore

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

因为支付天然是：

text 复制代码

长任务

例如：

text 复制代码

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

这本质就是：

text 复制代码

任务流

示例

ts 复制代码

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：

text 复制代码

用户一步一步操作

AI App：

text 复制代码

AI 自动完成整条流程

例如：

ts 复制代码

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

AI 可能：

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

如果没有：

text 复制代码

Task 边界
State 边界

整个系统一定：

text 复制代码

彻底失控

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

因为鸿蒙天然具备：

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

这些能力本质上都依赖：

text 复制代码

稳定状态流

一个非常关键的认知

很多人以为：

text 复制代码

鸿蒙核心是 UI

其实真正核心是：

Task Flow + State Flow。

因为：

text 复制代码

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

十一、推荐一个完整结构

text 复制代码

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

每个领域独立

例如：

text 复制代码

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

整个系统会稳定很多。

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

不是：

text 复制代码

页面很多
功能很多

而是：

text 复制代码

结构极其清晰

通常具备：

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

这些东西：

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

十三、总结

如果用一句话总结：

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

text 复制代码

状态系统

订单：

text 复制代码

状态机系统

支付：

text 复制代码

长任务系统

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

text 复制代码

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

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

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

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

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

记住一句话：

text 复制代码

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

它们本质上都是：

长期运行的系统能力。

当你真正建立：

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

你会明显感觉到：

text 复制代码

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