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

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

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

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

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

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

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

引言

很多开发者第一次接触鸿蒙分布式能力时，都会被这样的场景吸引：

手机修改数据
平板自动同步

平板继续编辑
PC实时更新

多个设备共享同一份数据

看起来像这样：

Phone
  ↓
Cloud
  ↓
Pad
  ↓
PC

于是很多人会产生一个错觉：

分布式同步 = 数据同步。

实际上并不是，真正上线后，问题很快就会出现：

手机修改订单

平板没有更新

或者：

两个设备同时修改

数据冲突

甚至：

UI疯狂刷新
状态错乱

最后：

分布式能力看起来能用

但体验非常差

因为：

分布式同步本质上不是技术问题，而是架构问题。

一、什么是分布式数据同步

一句话解释：

让多个设备共享同一个状态。

例如，用户登录后：

Phone
Pad
PC
TV

都应该拥有：

{
  "userId": "1001",
  "name": "Tom"
}

而不是：

每个设备维护一份

否则：

状态一定不一致

二、为什么很多项目同步体验很差

因为大家的第一版通常这样写：

await kvStore.put(
  "user",
  user
)

然后：

const user =
  await kvStore.get("user")

看起来：

同步成功

但问题是：

业务状态
直接绑定存储状态

最终：

状态来源混乱

三、真正的问题：UI直接依赖分布式数据

很多项目这样写：

@State user =
  await kvStore.get("user")

问题：

另一设备修改
       ↓
KV同步
       ↓
UI刷新
       ↓
用户操作中断

例如，用户正在填写订单：

输入中...

突然：

分布式状态更新

页面重新渲染，结果：

体验崩溃

四、正确的分布式架构

推荐结构：

Distributed Store
         ↓
Repository
         ↓
Domain Store
         ↓
UI

注意：

UI
永远不要直接操作分布式数据

五、第一层：Distributed Store

负责：

设备同步
状态同步
数据广播

示例：

export class DistributedStore {

  async set(
    key: string,
    value: Object
  ) {

    await kvStore.put(
      key,
      JSON.stringify(value)
    )

  }

}

读取：

async get(key: string) {

  return await kvStore.get(key)

}

这里只负责：

同步

不负责：

业务

六、第二层：Repository

Repository 是同步层和业务层之间的隔离层，例如：

class UserRepository {

  async getUser() {

    return await distributedStore.get(
      "user"
    )

  }

}

写入：

async saveUser(user) {

  return await distributedStore.set(
    "user",
    user
  )

}

Repository 的作用：

隔离底层实现

未来：

KVStore
CloudDB
本地数据库

都可以替换。

七、第三层：Domain Store

真正的业务状态必须在这里，例如：

class UserStore {

  user?: User

}

同步：

async sync() {

  this.user =
    await repository.getUser()

}

更新：

async update(user) {

  await repository.saveUser(user)

  this.user = user

}

这里：

Store
成为唯一状态源

八、为什么 Store 才是核心

很多项目：

KVStore 是状态源

这是错误的。因为：

KVStore
只是同步介质

真正状态源应该是：

Domain Store

例如：

orderStore
userStore
cartStore

这样：

状态边界清晰

九、一个用户同步 Demo

假设：

手机修改昵称

需要同步到：

平板
PC

UserStore

export class UserStore {

  user?: User

  async updateName(
    name: string
  ) {

    const newUser = {
      ...this.user,
      name
    }

    await repository.saveUser(
      newUser
    )

    this.user = newUser

  }

}

UI

Button("修改昵称")
  .onClick(async () => {

    await userStore.updateName(
      "OpenHarmony"
    )

  })

十、监听同步事件

同步成功后：

其他设备
收到变更通知

示例：

kvStore.on("dataChange",
  async () => {

    await userStore.sync()

  }
)

流程：

Phone 修改
      ↓
KV同步
      ↓
Pad收到通知
      ↓
Store更新
      ↓
UI刷新

十一、订单同步实战

订单系统更复杂，例如：

Phone 创建订单

平板：

立即看到新订单

推荐结构：

OrderStore
       ↓
OrderRepository
       ↓
DistributedStore

创建订单

async create(order) {

  const list =
    await repository.list()

  list.push(order)

  await repository.save(list)

}

同步订单

async syncOrders() {

  this.orders =
    await repository.list()

}

这样：

所有设备
始终读取同一个数据源

十二、为什么会出现同步冲突

这是分布式系统最经典的问题，例如：

Phone 修改昵称

Pad 同时修改昵称

结果：

谁生效？

错误做法

最后写入覆盖

可能导致：

数据丢失

十三、解决方案：版本号

推荐：

{
  "name":"Tom",
  "version":100
}

更新：

if (
  remote.version >
  local.version
) {
  replace()
}

这样：

最新版本生效

十四、AI Native App 为什么更依赖同步

传统 App：

用户修改状态

AI Native App：

Agent 修改状态
Task 修改状态
Workflow 修改状态

例如：

await agent.run(
  "帮我整理今天会议"
)

可能：

• 创建日程
• 修改提醒
• 写入笔记
• 更新任务

如果：

多个设备不同步

AI 结果会立即失效，所以：

AI Native = 分布式 Native。

十五、Assistant State 同步

未来 AI 助手会维护：

当前任务
执行状态
历史上下文

例如：

class AssistantState {

  currentTask: string

  progress: number

}

同步：

Phone
 ↓
AssistantState
 ↓
Pad
 ↓
PC

这样：

手机启动任务

平板继续查看

才能真正成立。

十六、为什么同步架构最终都会走向 State Center

很多项目：

设备同步
直接更新UI

后期一定失控，最终都会演变成：

Distributed Layer
         ↓
State Center
         ↓
UI

例如：

AssistantState
UserStore
OrderStore

统一管理，因为：

同步的是状态，而不是页面。

十七、未来的鸿蒙分布式架构

未来比较稳定的结构：

UI
 ↓
Store
 ↓
Task
 ↓
System
 ↓
Repository
 ↓
Distributed Store

这里：

Store

负责：

状态

Task

负责：

流程

Distributed Store

负责：

同步

职责完全独立。

十八、总结

如果用一句话总结：

分布式同步的本质，不是同步数据，而是同步状态。

很多项目同步失败，并不是因为：

• KVStore 不稳定
• 网络不好
• API 不够强

真正的问题是：

状态边界没有设计

过去：

一个设备
一个状态

未来：

多个设备
共享同一个状态系统

所以：

分布式能力
本质上是状态管理能力

很多开发者刚接触鸿蒙分布式时，关注的是：

• 设备发现
• 数据同步
• 跨端传输

但真正决定体验的，其实是：

状态同步架构。

记住一句话：

同步的不是数据，

而是整个应用的状态。

当你的鸿蒙 App 开始拥有：

• Distributed Store
• Repository
• Domain Store
• Assistant State
• Task State
• State Center

你会发现：

手机、平板、PC

不再是三个应用，

而是同一个应用在不同设备上的延伸。