AI 生活应用的离线策略模型不可用时产品也不能变成空白页一、离线不只是网络断连还包括服务降级和成本控制AI 生活应用的离线策略通常只考虑网络断连的场景。用户在没有Wi-Fi的地铁上打开应用数据加载不了页面变成空白。这个场景确实需要处理但更常见的离线是服务降级——模型API限流、第三方服务故障、或者用户自己选择了省流量模式关闭AI功能。离线策略的目标不是模拟完整功能而是保证核心功能可用。日记记录不需要AI也能写消费记账不需要AI也能手动输入分类情绪标签不需要AI也能手动选择。AI是增强层基础功能必须在AI不可用时独立运作。二、离线策略的分层设计基础层独立、增强层降级应用功能应分为基础层和增强层。基础层完全本地运行增强层依赖AI服务。AI不可用时增强层降级为简单替代方案。flowchart TD A[应用功能] -- B{功能层级} B --|基础层日记写入、记账、标签选择| C[完全本地运行不依赖任何外部服务] B --|增强层AI摘要、智能分类、情绪分析| D[依赖模型API] D -- E{AI可用} E --|是| F[完整增强功能] E --|否| G[降级为简单替代] G -- H[摘要→手动标题输入] G -- I[智能分类→手动选择分类] G -- J[情绪分析→手动选择情绪标签] C -- K[用户体验核心功能不中断] F -- K G -- K降级方案的设计关键是不让用户感觉功能消失了。原来一键AI摘要的位置变成手动标题输入框原来智能分类的位置变成下拉选择框。UI 元素保持位置不变只是交互方式从自动化变成手动化。三、离线优先的数据存储策略// 离线优先策略本地数据优先服务端同步为辅 import { openDB } from idb; type DiaryEntry { id: string; content: string; date: string; localCreatedAt: string; syncedAt: string | null; aiSummary: string | null; }; // 本地存储日记数据始终先写入本地数据库 export async function saveDiaryLocally(entry: DiaryEntry): Promisevoid { const db await openDB(life-diary, 1, { upgrade(db) { db.createObjectStore(diary, { keyPath: id }); }, }); // 写入本地时标记为未同步 entry.syncedAt null; await db.put(diary, entry); } // 离线时的增强层降级摘要功能变为手动输入 export function getSummaryFallback(aiSummary: string | null): { type: ai | manual; content: string; } { if (aiSummary) { return { type: ai, content: aiSummary }; } // AI摘要不可用时提示用户手动输入标题 return { type: manual, content: 请输入一个简短的标题来概括今天的日记, }; } // 网络恢复后的同步队列逐条上传未同步的本地数据 export async function syncLocalData(): Promisevoid { const db await openDB(life-diary, 1); const allEntries await db.getAll(diary); const unsynced allEntries.filter((e) e.syncedAt null); for (const entry of unsynced) { try { await uploadToServer(entry); entry.syncedAt new Date().toISOString(); await db.put(diary, entry); } catch (error) { // 单条同步失败不阻塞后续条目 console.warn(日记 ${entry.id} 同步失败:, error); continue; } } }IndexedDB 作为本地存储方案是因为它支持结构化数据和较大容量通常50MB以上。日记内容、消费记录这些数据本地存储完全够用。单条同步失败时不阻塞其他条目确保同步队列不会因为一条坏数据而停滞。四、离线策略的服务端数据一致性挑战离线优先策略最大的挑战是数据一致性。用户在离线时修改了日记内容服务端可能也有这个日记的旧版本。网络恢复后同步时需要处理冲突。简单的冲突策略是最后写入获胜。比较本地修改时间和服务端修改时间新的覆盖旧的。这在日记场景下是合理的——用户通常只编辑自己的内容不会多人协作。但如果用户在两个设备上同时修改了同一篇日记最后写入获胜可能导致一个设备的修改被覆盖。更安全的策略是在冲突时保留两个版本让用户选择保留哪个。但这个交互增加了用户操作负担。生活应用里大多数用户不会同时在两个设备上编辑同一篇日记最后写入获胜在实践中足够可靠。离线策略还要考虑数据清理。本地 IndexedDB 的容量虽然大但不是无限的。超过3个月未同步的数据应该提示用户处理——要么同步要么确认删除。无限积累本地数据会导致存储压力和同步队列过长。五、总结AI 生活应用的离线策略要把功能分为基础层和增强层。基础层完全本地运行不依赖外部服务增强层在AI不可用时降级为手动替代方案。降级时UI元素保持位置不变交互方式从自动化变手动化。数据存储用 IndexedDB 离线优先网络恢复后逐条同步。冲突策略用最后写入获胜超过3个月未同步数据需提示处理。