题目与范围
为经常断网或流量成本高的用户设计离线优先产品。答案要覆盖目标人群、核心任务、离线行为、同步预期、冲突处理、MVP 和指标。
把离线优先当作产品承诺，而不是缓存清单。Android 指南将其定义为核心功能全部或关键子集在无网时仍可用；web.dev 也强调请求无法完成时要向用户清楚说明状态。
面试官考察什么
面试官考察用户分层、约束下的优先级、数据状态信任，以及把体验选择连接到结果的能力。好的回答会区分“离线可用”和“稍后同步”，让限制可见，而不是承诺整套产品无网运行。
作答前需要确认的问题
- 哪些用户、地点、设备和网络模式在范围内？
- 必须离线完成的单一任务是什么：阅读、创建、编辑、采集还是分享？
- 数据是否私密、协作、受监管或安全关键？
- 内容允许多旧，两个设备同时编辑时怎么办？
- 存储、电量、流量和支持成本有哪些硬约束？
30 秒回答框架
“我会从经常在盲区记录现场数据的工作人员开始。MVP 支持查看分配任务、创建草稿、附加小型证据并展示同步状态，但不承诺离线实时协作。本地数据源作为即时真相，待同步队列用幂等键上传，并把冲突交给用户确认。先衡量断网任务完成率、同步成功率、冲突解决时间、流量和支持请求，再扩大范围。”
分步深入
第一步：按网络和任务分层
不要把“网络差的人”当作一个群体。按任务、断网频率、设备能力和失败代价分层。记录凭证的配送员、记录病历的医护人员和查看票据的旅客需要不同离线保证。
第二步：按离线价值排序任务
按紧急程度、频率、数据大小和可逆性给任务排序。先做窄的关键路径：查看准备好的任务、采集输入、保存草稿或读取已下载内容。协作编辑和大媒体文件可后置。
第三步：明确产品状态
使用用户能行动的标签：已保存到设备、等待同步、已同步、需要处理冲突或上传失败。web.dev 提醒灰色或含糊的离线状态会让用户困惑；要明确现在可用什么、仍需网络什么。
第四步：定义数据真相来源
离线优先时，本地数据源应作为即时真相，再与服务端协调。说明哪些字段权威、如何比较版本，以及同步前用户能否撤销本地改动。
第五步：设计同步契约
把变更放入带幂等键的队列，只对安全操作重试，并展示进度。决定自动同步、手动同步还是两者兼有。网络失败时保留草稿，不要把本地保存伪装成服务端已发布。
第六步：选择冲突策略
独立字段可以逐字段合并；共享状态或数量更适合版本检查和冲突页面，而不是静默最后写入。要判断冲突是否足够少、能否展示两个版本而不泄露敏感数据。
第七步：定义 MVP 和灰度
首发只选一个人群、一个关键任务和有限本地数据。通过功能开关试点，测试飞行模式、弱网延迟，并在扩大保留量或附件大小前补齐恢复路径。
第八步：设置结果和护栏指标
主指标可以是断网完成目标任务的成功率，以及同步确认耗时。护栏包括数据丢失报告、未解决冲突、存储压力、电量、流量和支持请求。要与联网基线比较，并按网络质量分组。
权衡与边界
权衡一：新鲜度还是可用性
展示稍旧的任务列表可能胜过什么都没有，但时间戳和新鲜度承诺必须可见。安全关键或金融数据可能要求在线校验，不能乐观展示。
权衡二：本地存储还是隐私
更多本地数据更有用，但设备丢失时暴露面更大。最小化字段、加密敏感内容、过期下载，并提供清晰的删除和退出行为。
权衡三：自动同步还是用户控制
自动同步省事；计费流量或共享设备用户需要控制。提供默认值，并在必要时支持暂停或仅 Wi-Fi 同步。
失败演练与演进计划
演练一：设备离线一周
定义什么会过期、什么仍可编辑以及队列保留多久。用户应知道本地记录是否仍有效，是否需要重新确认。
演练二：两台设备修改同一记录
用具体例子展示冲突策略。自动合并会隐藏重要变化时保留两份值，并衡量解决时长。
演练三：同步成功但服务端拒绝变更
展示带原因和下一步的失败状态。保留本地草稿，阻止无限重试，并提供安全修正路径。
常见错误与追问
错误一：把离线当技术清单
先定义用户任务和失败代价，再考虑 Service Worker 或本地数据库等实现。
错误二：承诺完全一致
说清关键子集和有意排除项。无限离线范围会带来存储、隐私和支持问题。
错误三：隐藏同步状态
用户无法区分保存和发布，就无法信任结果。使用基于行动的状态、时间戳和可检查的重试路径。
错误四：所有冲突都最后写入
实现简单，却可能抹掉重要工作。只有业务影响低且可恢复时才使用。
错误五：只测联网留存
离线功能可能提升现场任务完成率，却不改变日活。埋点断网会话、同步完成和数据丢失投诉。
错误六：没有恢复演练就发布
上线前测试飞行模式、慢网络、存储已满、时钟变化、凭证过期和中断上传。