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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多人第一次把 HarmonyOS 应用迁移到 PC 时，都会很自然地保留一套东西：

router.push()
router.replace()
router.back()

因为过去十几年：

“页面跳转”几乎等于“应用逻辑”。

于是项目很容易变成：

首页
↓
详情页
↓
编辑页
↓
设置页

看起来结构清晰，但真正开始做：

• 多窗口
• 多面板
• 多任务
• AI 驱动
• 分布式协同

之后，你会越来越发现：

“页面跳转”正在成为整个系统最不稳定的部分。

甚至可以说：

在鸿蒙 PC 上，页面跳转本身就是一种“移动端遗留架构”。

一个很多人没意识到的问题

页面跳转的核心前提是什么？其实只有一句话：

同一时间，只存在一个主上下文

所以：

页面 A
↓
跳转
↓
页面 B

逻辑完全成立，因为移动端本质是：

单上下文串行系统

但鸿蒙 PC 完全不是这样

在鸿蒙 PC 上：

• 文件树在左边
• 编辑器在中间
• AI 面板在右边
• 第二窗口可能还开着设置页

也就是说：

多个上下文同时存在

这时候：

“跳转”这个概念本身就开始变得奇怪。

一、PC 真正发生的不是“跳转”，而是“状态切换”

这一点非常关键，很多开发者会写：

router.push('/editor')

但用户真实行为其实是：

当前文件变了
当前焦点变了
当前工作区变了

也就是说：

用户并没有“进入新页面”。

而是：

系统状态发生了变化。

二、页面模型最大的问题：它会“切断状态”

这是最致命的一点，很多代码会这样：

@Component
struct EditorPage {
  @State content: string = ''
}

然后：

router.push('/editor')

问题在于：

content 生命周期
绑定在页面实例上

页面销毁：

状态直接丢失

于是你开始：

• 缓存状态
• 保存草稿
• 手动恢复
• 同步页面数据

最后整个项目会变成：

“页面负责显示，Store 负责续命”。

三、为什么 Router 在鸿蒙 PC 上越来越“别扭”

因为 Router 本质上属于：

流程型架构

它解决的是：

用户下一步去哪

但 PC 真正的问题是：

当前有哪些状态同时存在

这是两种完全不同的问题。

四、多窗口会直接击穿页面模型

移动端：

一次一个页面栈

很简单，但在鸿蒙 PC：

WindowA
WindowB
WorkspaceC
PanelD

问题来了：

• Router 是全局的吗？
• 页面栈怎么隔离？
• 状态怎么同步？
• 焦点属于谁？

这时候你会发现：

Router 已经无法描述系统结构了。

五、真正的核心：Workspace，而不是 Page

在鸿蒙 PC 上，更合理的模型其实是：

class Workspace {
  workspaceState: WorkspaceState
  uiState: UIState
}

UI 只是：

Workspace 的投影

真正驱动系统的是：

状态

而不是：

页面

六、页面跳转会制造“伪生命周期”

很多问题其实都来自这里，比如：

aboutToAppear()
aboutToDisappear()

很多人会：

• 在这里初始化数据
• 在这里恢复状态
• 在这里同步内容

问题是：

这些逻辑，本质根本不属于页面。

而属于：

状态生命周期

页面生命周期只是：

UI 的生命周期

不是：

数据的生命周期

七、真正稳定的系统：状态先存在，UI 后生成

这是鸿蒙 PC 最关键的一步，传统模型：

进入页面
↓
初始化状态
↓
渲染 UI

鸿蒙 PC 更合理的模型：

状态先存在
↓
UI 自动映射

比如：

currentFileStore.open(id)

然后：

uiState.mainView = 'Editor'

UI 自动变化：

无需跳转

八、为什么 AI 会彻底淘汰“页面驱动”

这是未来最大的变化。

页面驱动

AI 很难知道：

当前在哪个页面
页面之间怎么跳
状态在哪里

因为状态散落在：

• 页面实例
• 生命周期
• Router 参数

状态驱动

AI 可以直接：

workspace.currentFile
workspace.selection
workspace.activePanel

然后：

自动更新状态

UI 自动变化，所以：

AI 天然适配“状态系统”，不适配“页面系统”。

九、为什么“Back”在鸿蒙 PC 上越来越不重要

这是一个非常明显的信号，过去：

router.back()

几乎是核心交互，但在 PC 用户更多是：

• 切换窗口
• 切换 Workspace
• 切换焦点
• 切换任务

而不是：

返回上一页

所以：

“页面返回”本质是移动端的流程型交互。

十、真正的问题：你到底在设计什么？

很多开发者其实一直没意识到：

自己设计的是：

页面流程

而不是：

状态系统

这会导致：

• 页面越来越多
• Router 越来越复杂
• 生命周期越来越混乱
• 状态越来越难同步

最终：

系统会慢慢失控。

十一、正确思路：去页面化

在鸿蒙 PC 上，你应该设计的是：

状态流
Workspace
UI 投影

而不是：

页面跳转树

错误模型

PageA → PageB → PageC

正确模型

State
 ↓
Workspace
 ↓
ArkUI

十二、本质总结：页面跳转是一种“移动端历史包袱”

这是最核心的一句话，很多人以为：

PC 只是“屏幕更大的移动端”

所以自然沿用：

Router
Page
Back

但实际上：

鸿蒙 PC 已经进入了“多状态并行系统”。

而页面跳转：

只适用于单状态串行系统

总结

在鸿蒙 PC 上，“页面跳转”不是最佳实践，而是一种架构惯性。

因为它会：

• 切断状态
• 制造伪生命周期
• 放大多窗口复杂度
• 破坏状态一致性

真正应该做的是：

状态驱动 UI
Workspace 组织上下文
系统管理状态流

而不是：

Page → Route → Back

最终你会发现：

鸿蒙 PC 最大的变化
不是“窗口”
而是“状态开始成为系统核心”

而页面跳转：

正在慢慢退出历史舞台。