移动应用后端、API与离线同步：让应用持续稳定运行的架构

本指南面向规划应用服务端的CTO、技术负责人和产品负责人。我们的移动产品开发指南简要覆盖从调研到规模化的完整路径；本页深入讲解后端、API契约与离线同步。应用本身的构建方式可参阅原生与跨平台移动开发对比。

目录

• 移动后端需处理哪些网站无需处理的问题
• 面向移动客户端的API契约
• 离线同步：四种模式
• 冲突处理与决策规则
• 登录、推送与设备安全
• 后端方案：备选方案与选择标准
• AI功能与后端
• 构建计划
• Netbase如何构建移动后端
• 现有交付记录与尚无记录的内容
• 本指南的局限性
• 常见问题
• 下一步

移动后端需处理哪些网站无需处理的问题

网站在每次部署后即对所有访客生效。移动应用则不然：用户自主选择更新时机，部分用户从不更新。这带来三个影响后端设计的结果。

• 同时存在多个客户端版本。服务器必须响应所有仍受支持的应用版本，因此一个字段重命名或新增必填参数，可能在一夜之间导致数千个已安装应用出错。
• 请求可能中途失败。请求已到达服务器，但响应在返回途中丢失。应用重试，若后端处理不当，则会创建第二笔订单或第二笔付款。
• 离服务器较远的工作场景。外勤人员、出差者和地下室购物者在无信号时打开应用，期望应用正常工作，并期望其变更稍后能同步上来，且不覆盖他人的修改。

面向移动客户端的API契约

将API视为有其自身规则的产品，而非Web前端的副产品。

• 有意识地进行版本管理。可以自由新增字段，但在受支持的应用版本仍在读取某字段期间，不得删除或重命名该字段。将破坏性变更置于新版本之后，发布最低支持应用版本，并由后端通知旧版应用进行升级。
• 按屏幕裁剪响应。后端前置层（BFF）是一个精简服务，专门组装某个屏幕所需的数据，可减少慢速网络上的往返次数，同时避免将内部系统暴露给应用。
• 使用游标分页。使用游标而非偏移量对列表分页，避免用户滚动时新增记录被重复显示或被跳过。
• 确保创建操作可安全重试。RFC 9110将POST定义为非幂等，因此每次创建请求都应携带设备生成的幂等键；服务器将其与结果一并存储，并在重试时返回首次结果。
• 按设备需求发送数据。按设备调整图片尺寸、压缩响应，并仅发送自应用上次同步标记以来变更的记录。
• 返回应用可处理的错误。稳定的错误码告知应用应重试、重新认证还是终止操作。

当同一后端还需服务网站、合作伙伴和内部系统时，相关流程规则可参阅我们的企业系统集成指南。

离线同步：四种模式

按数据类型选择同步模式：目录、草稿表单与支付所需的保障各不相同。

• 仅在线，带读缓存。应用展示最近获取的数据，离线时阻止变更。适用于价格、库存及所有必须实时的数据。
• 写入队列。变更存入发件队列，待连接恢复后按序发送。Android的离线优先指南将此模式列为适用于分析事件和日志等数据的方案。
• 本地优先数据。应用读写本地数据库，由同步进程与服务器交换变更。Android指南将本地来源称为“应用的权威数据源”；适用于笔记、检查记录和外勤记录。
• 托管同步服务。平台保持本地数据库与服务器副本同步并提供冲突处理，代价是需要采用其数据模型。

同步本身以按需（拉取）或服务器通知应用变更（推送）两种方式运行；Android指南建议短时间离线使用拉取，长时间离线及关联数据使用推送。

冲突处理与决策规则

当两人同时修改同一条记录，其中一人处于离线状态时，必须有一方的修改胜出。在首次构建之前，按字段以书面形式确定规则。

• 最后写入胜出。每次变更携带时间戳，保留较新的一条。适用于单人拥有的数据，如个人资料或草稿。
• 服务器规则。仅当记录版本与设备所见一致时，后端才接受变更；否则应用展示当前状态并询问用户。
• 按字段合并。对不同字段的变更均予保留；只有同一字段的冲突才需要规则。
• 永不离线。支付、库存预留和审批在线时由服务器确认，无论应用其他部分如何处理。

在服务器维护包含设备、用户、版本和结果的同步日志，以便支持团队解释某条记录的处理过程。

登录、推送与设备安全

登录。移动应用无法保守秘密：IETF RFC 8252将原生应用归类为公共客户端，要求OAuth使用PKCE扩展，并在系统浏览器而非内嵌Web视图中打开登录页面。使用短期访问令牌，将刷新令牌保存在平台的安全存储中，并在此基础上提供生物识别解锁。

推送。Firebase Cloud Messaging将自身描述为跨平台消息解决方案，分为系统展示的通知消息和应用自行处理的数据消息。发送数据消息以触发应用同步，发送通知消息用于用户必须看到的内容，并在用户能理解的时机请求权限。

安全。OWASP移动应用安全验证标准将存储、加密、认证、网络通信和弹性的控制措施进行了分组。在服务器端，每个端点自行检查用户权限，无论应用展示或隐藏了什么。

后端方案：备选方案与选择标准

四个标准决定选择：谁目前拥有数据、产品有多少功能在离线状态下运行、应用需要接入多少系统，以及谁负责在夜间运维后端。当后端还需与商店、ERP和CRM对接时，请先使用ERP、CRM与电商平台集成架构设计这些流程；Netbase的系统与API集成服务可构建该层。

Netbase如何构建移动后端

Netbase使用React Native构建跨平台应用，这是其长期招募的技术方向，所使用的技术栈详见后端平台页面。团队规模从3人到30人不等，涵盖分析师、架构师、开发人员、QA和设计师，通常在调研结束后1至2周内开始工作。Netbase的大多数项目以调研后商定的固定总价合同交付（参见专属开发团队与固定总价对比），在定制开发中，客户拥有为其创建内容的知识产权。安全实践涵盖安全代码审查、传输层TLS加密、静态AES加密、基于角色的访问控制以及管理员仪表盘的MFA。请查看移动应用开发服务，或在可复用构建模块适用时查看移动产品加速器。

现有交付记录与尚无记录的内容

• 现有记录。RB Marketplace记录描述了一款基于市场自有API构建的消费者购物应用（经过API审计），具备推送通知、服务器同步心愿单和离线浏览功能，面向Android，iOS在扩展范围内。Dey Page记录描述了一款适用于iOS和Android的React Native应用，与Web目录共用同一后端，支持手机OTP账号、推送和深度链接；其带离线同步的外勤数据采集运行在移动Web应用中。积分商店记录描述了为客户自有应用提供的移动UI组件，以及通过Webhook和定时同步与客户系统的数据同步；客户未具名。
• 尚无记录。上述记录均未发布下载量、使用量、正常运行时间、同步量或错误率，且RB Marketplace记录未注明所用框架。上述记录均不作为某种同步模式或后端方案性能更优的证明。

本指南的局限性

• 平台声明来自访问日期时的Android、IETF、Firebase和OWASP页面；平台会更新，请查阅当前版本。
• 同步模式适用于商业、电商和外勤应用；实时协作和游戏需要专门设计。
• 安全实践可降低风险；这并非对任何应用或后端的保证。

常见问题

现有Web后端能否服务移动应用？通常可以，通过添加版本管理、缓存和按屏幕裁剪响应的精简移动层实现。仅在核心过慢或无法安全修改时才重建。

旧版应用应支持多长时间？只要仍有相当比例的用户在使用。发布最低支持版本，并在提升之前提前告知。

每款应用都需要离线模式吗？不需要。按数据类型决定：读缓存成本低，而离线变更需要队列、冲突规则和更多测试。

如何防止重试请求创建重复订单？设备生成幂等键并由服务器与首次结果一同存储，重试时返回该结果而非创建第二笔订单。

下一步

告知您的应用需要离线保存哪些数据、需要读取哪些系统以及当前已在使用的应用版本，我们将安排解决方案评审，梳理API契约并为每种数据类型规划同步模式。您也可以查看移动应用开发或更多Netbase洞见。

相关服务与解决方案