关于 应用状态管理 最流行的建议往往也是最没用的：选一个全局 store 然后把所有东西都塞进去。这种做法将 API 响应、弹窗可见性、未保存的表单输入、身份验证和导航过滤器视为具有相同的生命周期。事实并非如此。Capacitor 或 Electron 应用运行在 Web 层与原生或桌面运行时之间，因此必须根据以下维度对状态进行隔离： 来源、生命周期、所有权，以及网络或进程消失时的处理逻辑.
状态管理之所以成为核心，是因为移动端运行时具有不稳定性。应用可能会在屏幕旋转或低内存条件下被销毁并重建，而 Android 提供了实例状态恢复和生命周期回调，例如 onSaveInstanceState() 出于这个原因，正如在以下文档中所述： 加州大学河滨分校关于可靠移动应用状态管理的调研。该项研究还调查了 966 个应用和 4,808 个 Activity，结果发现 452 个应用（占比 46.8%）至少包含一个具有非空状态的 Activity，而 1,896 个 Activity 整体具有非空状态。状态并非 UI 开发完成后才添加的可选抽象，它是运行时契约的一部分。
目录
- 重新思考全局 Store 模型
- 跨平台应用的架构模式
- 持久化与离线优先同步
- 性能调优与测试策略
- Capacitor 与 Electron 的平台特定指南
- 迁移至现代混合架构
- 最佳实践与应避免的常见错误
重新思考全局 Store 模型
纠结于 Redux、Context 还是 MobX 是错误的切入点。Store 可以协调更新，但它无法决定一个值是属于服务端、当前页面、表单工作流还是地址栏。将所有值都塞进一个全局容器会导致 API 缓存重复、URL 参数陈旧，以及引发无关页面重新渲染的订阅问题。
一个稳健的设计会为每个值分配所有者和恢复策略：
- 服务端状态 (Server state) 属于数据获取与缓存层。API 响应、加载状态、错误、新鲜度、失效及重试都描述的是远程资源。服务端始终是权威数据源，因此客户端不应维护第二个永久性的事实来源。
- 客户端或 UI 状态 (Client or UI state) 应靠近拥有它的组件或功能。弹窗可见性、选中的标签页、展开的行、主题偏好以及临时交互标志通常不需要应用级的持久化。
- 表单状态 (Form state) 遵循独立的流程。草稿输入、校验信息、脏状态（dirty status）以及提交进度可能需要在表单内导航时得以保留，但不应自动成为共享的业务状态。
- URL 状态 属于路由管理。地址栏中的搜索词、过滤器、排序选项、选定记录和分页信息可以被收藏、分享、恢复和检查，而无需将其复制到另一个 store 中。
为什么单一 store 会造成架构拖累
2024 年 应用状态管理深度回顾 探讨了 Web 和移动端应用的状态管理。其涵盖范围反映了从零散的 UI 变量向显式、感知生命周期的架构转变。Android 从 instance-state bundles 向 ViewModel 和 SavedStateHandle 的演进也遵循这一方向，但这并不意味着所有值都应该放在一个共享容器中。
全局 store 仍有其明确的角色。会话身份、权限、应用级偏好、连接策略以及经过严格边界划分的跨功能工作流可能需要共享所有权。当该 store 变成那些本该由其他组件负责的值的“垃圾场”时，问题就开始了。
实用原则： 如果一个值可以通过服务器、URL 或当前组件重新构建，除非特定工作流有特殊要求，否则请不要将其放入全局状态。
这种边界也支持独立拥有的模块。将产品拆分为可部署区域的团队可以应用以下所有权原则： 微前端架构，而不是在整个应用中构建单一的依赖图。在 Capacitor 或 Electron 代码库中，混合模型效果更好：远程数据使用缓存和同步规则，UI 值保持本地化，而持久化工作流状态则进行显式持久化。这种分离限制了冲突写入，并使应用在重新加载、进程挂起或离线后的恢复逻辑更易于理解。
跨平台应用的架构模式
一旦状态有了所有者，实现方式的选择就会变得非常明确。大多数客户端状态符合以下三种模式之一： 局部组件状态，一个 小型共享 Store，或者 事件驱动通信 用于隔离模块之间。没有哪种模式是绝对优越的。通常，当团队在确定更新频率、所有权和恢复需求之前就选择了某种模式时，就会出现错误的选择。
| 模式 | 复杂度 | 内存占用 | 最佳使用场景 |
|---|---|---|---|
| 组件本地状态 | 低 | 低 | 特定页面的开关、草稿、折叠面板、临时选择 |
| 轻量级中心化 Store | 中等 | 中等 | 共享会话偏好、主题、当前工作区、跨功能 UI 协同 |
| 事件总线架构 | 中到高 | 变量 | 松耦合模块、插件通知、原生桥接事件、隔离的功能边界 |
应优先使用本地状态
组件级本地值的依赖路径较短。当模态框打开、行展开或表单字段变化时，所属功能模块可以直接更新，无需通知整个应用。这减少了意外耦合，使单元测试更直接。同时，在移动端屏幕挂起或桌面端窗口长时间开启时，也能限制内存占用。
当多个远端功能需要共享同一数值，或工作流跨越路由边界时，使用本地状态会变得很棘手。在这种情况下，将状态提升到功能 Store 通常比放在全局单例中更好。使用 Zustand 或 Pinia 等轻量级 Store 可以提供专注的 Selector 和明确的 Action，而无需让每个组件都订阅所有变更。
权衡在于开发规范。轻量级 Store 极易创建，因此团队可能会产生大量重叠的 Store 且权责不明。请明确其所有者，定义 Mutation 方法，并避免暴露任何组件都能修改的可变对象。
事件很有用，但它们不是数据库
事件总线（Event Bus）非常适合处理“原生分享已完成”、“窗口变为活跃”或“后台任务收到新数据”这类通知。它能让插件和模块在无需互相导入的情况下进行通信。但由于事件是瞬时的，它不适合作为业务状态的唯一记录。如果订阅者被挂起、卸载或注册过晚，可能会错过消息。
用事件通知某事已发生，然后让接收模块查询其权威存储或数据层。事件名称要尽量具体，payload 要带版本，因为原生端和 Web 端的 code 可能会各自演进。
从更广泛的架构层面来看， 来自 Bridge Global 的移动应用开发见解 在权衡共享 code 与平台特有行为时很有用。同样的边界也适用于应用状态：在稳定之处共享领域规则，但隔离生命周期适配器和原生集成点。一个实用的 移动应用架构指南 应该在文件夹结构和依赖图中清晰地体现这些边界。
持久化与离线优先同步
内存存储（In-memory store）并非持久化状态。操作系统可能会挂起或终止移动端进程，桌面用户可能会关闭窗口，而网络也可能在数据变更进行中中断。离线优先设计首先要确定用户必须能恢复哪些数据，然后围绕这一需求选择存储和同步规则。
构建持久化的写入路径
一个可靠的工作流会将即时用户体验与远程确认过程分离：
- 优先进行本地写入。 将用户操作应用于本地数据库或持久化文档存储，使界面无需等待网络响应即可即时反馈。
- 将变更操作入队。 存储包含实体 ID、操作类型、负载、创建上下文及重试状态的操作。仅存在于内存中的队列会在进程结束时丢失。
- 渲染真实的同步状态。 区分已本地保存、同步中、已同步和失败状态。用户需要明确变更是在设备上已持久化，还是已在远程端得到确认。
- 在条件允许时进行同步。 重新连接监听器、应用进入前台事件以及计划的任务都可以触发重试。由于中断的请求可能会被再次发送，同步 worker 必须具备幂等性。
- 有意识地解决冲突。 必须通过服务器响应来确定本地操作是被接受、拒绝、合并，还是需要用户介入处理。
对于原生支持的应用，SQLite 是处理关系型记录和事务队列的实用选择。如果团队能谨慎处理 schema 升级和事务边界，IndexedDB 则适用于面向浏览器的存储和 Electron 渲染进程 code。保持序列化过程显式化。持久化领域数据和恢复元数据，而不是组件实例、闭包或原生对象的引用。
冲突策略是一项产品决策
最后写入者胜 (Last-write-wins) 虽然简单，但可能会丢弃有效的编辑。当独立字段可以安全合并时，字段级合并 (Field-level merging) 非常有效。对于库存、审批、财务记录或临床工作流等自动合并可能改变含义的场景，使用特定领域的业务规则更安全。某些冲突应当阻止同步，并提示用户进行选择。
同步层还应当分离 读取对账 (read reconciliation) 与 变更重放 (mutation replay)。重新获取服务器数据并不能证明队列中的 mutation 已成功，而重放 mutation 也无法保证生成的记录仍与服务器当前状态一致。应记录服务器版本或等效校验器，返回结构化的冲突响应，并保留足够的队列历史记录以解释失败原因。
针对该设计的用户交互部分， 在 Vue、Angular 或 React 中创建离线界面 提供了一个重要的接口设计思路：离线模式应当是应用中可见的状态，而不是隐藏在控制台里的异常。
以下视频可以为离线行为与同步相关的实现工作提供补充：
性能调优与测试策略
状态性能问题很少是由单个缓慢的 reducer 引起的。它们通常源于：广泛的订阅导致无关组件重新渲染、派生值（derived values）进行不必要的重新计算、大型对象图持续被引用，或者同步工作运行在 UI 线程上。你应该测量更新传播的实际情况，而不是盲目猜测哪个库最快。
一项 2026 年的基准测试，通过使用包含 100 个连接组件和 10,000 次迭代的 dashboard 测得 MobX 在 简单变更下为 0.3 ms，嵌套变更下为 0.4 ms，派生变更下为 0.6 ms，而 Redux Toolkit 在 相应测试中的表现为 0.8 ms、1.2 ms 和 1.5 ms 。同一基准测试在 内存对比中记录了 Zustand 为 2.8 MB，Redux Toolkit 为 4.2 MB 。这些是特定基准测试下的观察结果，并非通用的生产环境保证，但它们说明了订阅粒度和更新策略的重要性。请参阅 React 状态管理对比基准测试 用于测试上下文。
优化更新边界
从 Selector 开始。组件应该订阅最小的有意义的数据切片，而不是整个 session 对象或 API 响应。当计算开销较大时，请对派生数据进行 memoization，但不要出于惯性对每个基本类型都进行 memoize。Memoization 也会增加内存占用和比较开销，因此请在操作前后进行性能分析。
对长列表进行虚拟化处理；当更新针对单个实体时，请对记录进行规范化（normalize），并避免因微小的字段变更而替换整个大型根对象。在 Electron 中，由于窗口存活时间可能远长于移动端屏幕，请在长时间运行期间监控渲染器内存。在 Capacitor 中，避免在输入高峰期进行同步持久化。对草稿进行防抖（debounce）或持久化关键检查点，同时确保即使发生崩溃，也不会丢失产品承诺保留的数据。
一项与 Springer 相关的研究发现，改变状态管理方法使程序的平均执行时间减少了 在测试场景中达到 17%，这证明了减少不必要的同步和重复计算可以带来显著的运行时收益。该结果出现在 关于 Web 应用状态管理性能的研究中，但不应将其视为对所有技术栈都有保证的改进。
测试状态转换，而非仅仅测试值
如果状态测试仅检查 isLoading 在请求成功后的情况，就会忽略危险路径。请测试以下序列：
- 注水 (Hydration): 持久化数据加载，拒绝无效记录，仅对缺失字段填充默认值。
- 中断 (Interruption): 在执行 mutation 时请求被取消或应用进入后台。
- 重放 (Replay): 队列中的操作安全重试，且不会导致服务器端产生重复副作用。
- 冲突 (Conflict): 服务器拒绝过时版本，UI 提供可恢复的冲突解决方案。
- 隔离 (Isolation): 本地 UI 更新不会导致无关功能重新渲染或发生 mutation。
在网络边界处使用 Mock server-state 适配器，随后通过集成测试覆盖完整工作流。在开发和 CI 环境中加入埋点，以检测异常的订阅数、无限制的队列以及组件卸载后发生的 state 转换。最有价值的测试 fixture 通常是真实的生命周期序列，而非单纯的 reducer 断言。请参考 应用性能优化指南 将这些指标转化为可重复的发布检查。
Capacitor 与 Electron 的平台特定指南
Web 应用通常认为其 JavaScript 进程的存续时间比移动应用更长。Capacitor 和 Electron 以不同的方式打破了这一假设。Capacitor 将 Web 层置于由 iOS 或 Android 管理的移动生命周期内，而 Electron 则保持 Chromium 渲染器连接到桌面进程模型，其窗口可以独立出现或消失。
Capacitor 需要具备生命周期感知能力的注水 (hydration)
将应用进入后台视为一个检查点，而非进程一定会恢复的证明。在应用状态发生变化时，请刷新关键的待处理变更 (mutations)，记录当前的同步游标，并释放不应保持活跃的资源。在应用回到前台时，重新注水 (rehydrate) 已丢失的数据，验证身份认证，刷新过期的服务器数据，并仅在本地 Store 就绪后才重启订阅。
JavaScript store 不应直接持有原生插件的内部状态。Camera 会话、生物识别 prompt、推送注册、文件系统句柄以及后台任务都遵循各自平台的生命周期规则。应将它们封装在适配器中，将原生回调转换为领域事件或命令。这样，store 就可以表示“不可用”、“请求中”、“活跃”、“失败”或“已完成”等状态，而无需保留在应用挂起后会失效的原生对象。
Webview 的边界也决定了序列化的重要性。通过 Capacitor 桥接传递纯数据，验证插件响应，并在 live update 可能导致不同的 web bundle 与已安装的原生 code 进行交互时，对消息进行版本管理。 Capacitor 如何桥接 Web 与原生 code 解释了为何这种适配器方案是必要的边界条件。
Electron 需要进程所有权
Electron 的主进程应负责特权操作和持久化协调，而渲染进程则负责视图特定的状态。对于读取安全设置、写入文件或协调窗口等操作，请使用类型化的 IPC 命令。不要向每个渲染进程开放广泛的文件系统访问权限，也不要将发送给单个窗口的事件视为持久的应用记录。
多窗口应用需要明确的同步模型。主进程负责分发权威更新，而每个渲染进程维护本地展示状态。如果两个窗口编辑同一条记录，应用需要进行版本检查或冲突处理策略，而不仅仅是广播事件。关闭的窗口在重新打开时必须能够重建状态，因此主进程或持久层必须作为可恢复数据的唯一来源。
Capacitor 与 Electron 可以共享领域模型、API 客户端、队列格式和 reducers。但它们不一定需要共享生命周期 code。最强大的跨平台架构应具备通用的状态词汇表，以及针对特定平台的持久化、桥接和恢复适配器。
迁移至现代混合架构
传统的全局 Store 很少需要重写。它需要的是一次盘点和一系列安全的提取过程。当每个功能可以逐个迁移状态类，同时旧 Store 仍能为未改动的页面提供服务时，迁移效果最好。
从所有权开始，而非技术
为现有 store 创建一份状态目录。记录每个字段的数据源、消费者、变更路径、持久化需求及恢复行为。标注其属于服务端派生、路由派生、表单持有、功能局部还是全局共享。通过这项练习，你通常会发现全局 store 其实是隐藏在单个 API 之后的多个无关系统的集合。
优先迁移服务端状态。将手动镜像的 API 字段替换为专门的获取与缓存层，由该层管理请求状态、失效、重试和重新验证。暂时保持 selector 的兼容性，以便现有页面无需一次性修改所有调用点即可完成迁移。只有在新数据源通过集成测试后，才删除重复的服务端副本。
接下来，将 URL 状态归还给 router。搜索过滤器和选中的资源应通过路由参数或查询状态（query state）在页面刷新或分享时得以保留。移除那些将 URL 值同步到 store、再将 store 值同步回 URL 的副作用（effects）。这种循环会导致竞态条件，并降低浏览器历史记录的可信度。
逐步提取功能状态
将弹窗状态、向导进度和局部选择迁移到最近的功能边界内。如果多个组件需要该值，请使用接口精简的功能 store。将剩余的全局 store 留给跨功能的通用需求，例如会话策略、主题、权限或明确的共享工作流。
在过渡期间使用兼容层。它可以从新数据源读取，同时保留旧的 selector 结构，从而允许在功能开关（flags）的控制下进行迁移。独立发布每次提取的内容，监控错误路径和 hydration 行为，并在新的所有权模型证明稳定之前，始终保留回滚方案。
对于 Capacitor 和 Electron 团队，Capgo 可以通过定向渠道交付经过签名的 JavaScript、CSS、配置和资源 bundle，并提供发布控制、版本历史、设备 logs、采用率与失败指标以及自动回滚保护。这使得在原生变更仍遵循相关平台发布流程的同时，能够增量式地完成状态管理重构。其运维优势在于对迁移过程的掌控力，而非跳过测试或兼容性规划的理由。
最佳实践与应避免的常见错误
如果评审问题过于模糊，状态架构就会失效。请在设计评审和 pull request 中使用以下检查项：
- 在 code 中明确所有者： 询问：“哪个模块可以修改此值，以及 API 如何强制执行该边界？”拒绝仅因为两个组件当前需要同一个字段而添加的 store。
- 定义恢复契约： 对于每个持久化值，需记录在重新加载、应用重启、登出和切换账号时，该值是会被保留还是被清除。例如，草拟的账单在重启后可能依然存在，而选中的工作区则可能需要重新验证。
- 使同步过程可观测： 记录请求 ID、版本、重试次数及冲突结果。在用户发现更新缺失前，针对重复重试或冲突失败设置告警。
- 审查命令，而非对象结构： Mutation 应明确业务意图、校验输入并提供易于审计的操作名称。绕过这些检查的直接写入操作应在 Code Review 中讨论。
- 测试异常序列： 针对以下场景运行测试：与导航冲突的 Hydration 竞态、中断写入后的重试、重复交付、双窗口离线编辑，以及挂起请求时的登出操作。
- 检查移除路径： 如果旧的 Selector、持久化适配器或事件监听器仍在向原 Store 写入数据，则迁移是不完整的。应添加测试，确保当两个数据源尝试更新同一字段时会触发失败。
一个实际的 PR 问题是：“如果进程在写入开始后、确认收到前消失了，会发生什么？”答案应涵盖持久化数据、重试权责、去重机制以及用户可见的失败状态。
Capgo 帮助 CapacitorJS 和 Electron 团队通过定向渠道发布 JavaScript、CSS、配置和资源更新，并提供签名 Bundle、发布控制、设备级 Logs 和回滚保护。使用 Capgo 来增量交付状态管理重构和修复补丁，随后通过生命周期和同步测试进行验证。
