对话记录丢失通常不是程序突然崩溃造成的，而是浏览器把站点数据连同缓存一起清掉了。很多聊天页面会把消息数组写入localStorage，用来实现刷新后历史仍然可见，但这种做法对用户主动清理浏览器数据几乎没有任何抵抗能力。要稳定保留对话历史，需要把本地存储和服务端同步结合起来，单纯依赖其中一种都会留下数据缺口。下面先拆解浏览器清理机制，再给出可落地的同步与恢复方案。

一、为什么浏览器清理缓存会连对话记录一起删掉

从浏览器视角看，localStorage、sessionStorage、IndexedDB、Cache Storage都属于站点数据的一部分，并不只是HTTP缓存。用户在设置里勾选“清除浏览数据”时，只要包含了“Cookie 及其他站点数据”，这些存储区域都会被一并删除。因此即使你用的是IndexedDB而不是localStorage，清理操作同样会清空对话记录。区别只在于sessionStorage会在标签页关闭时立即消失，而localStorage和IndexedDB通常能保留到用户主动清理或浏览器空间不足时被淘汰。

下面这段代码是用localStorage保存聊天记录的常见做法，它虽然能让页面刷新后恢复消息，但无法防止用户在浏览器设置里点一次“清除数据”把记录全部带走。

function saveMessagesLocal(messages) {
  try {
    localStorage.setItem('chat_history', JSON.stringify(messages));
  } catch (e) {
    console.error('保存失败', e);
  }
}
function loadMessagesLocal() {
  const raw = localStorage.getItem('chat_history');
  return raw ? JSON.parse(raw) : [];
}

localStorage的另一个问题是容量通常只有5MB左右，聊天消息一多就会触发QuotaExceededError。IndexedDB虽然容量更大、操作异步，但本质上仍然是绑定当前源的数据仓库，清理站点数据时一样会被删除。所以把记录只放在浏览器本地，等于把数据安全完全交给了用户的清理习惯，风险很高。

还有一个容易被忽略的场景：浏览器在磁盘空间紧张时，会自动清理一部分较少使用的源数据。即使你从不手动清理缓存，一段不活跃的聊天应用也可能被浏览器回收存储空间，导致历史记录悄无声息地消失。这种策略在移动端浏览器上尤其常见。

二、历史同步：把对话记录落到服务端才是可靠方案

要彻底避免对话记录丢失，最核心的办法是每次发送或接收消息时，都向服务端写入一份。服务端数据库不会因为用户清理浏览器缓存而改变。页面初始化时再从服务端拉取历史记录，即使本地缓存全部被清空，只要用户登录同一账号，对话仍然能够完整恢复。这里的关键不是“同步”这个词本身，而是把服务端作为唯一可信数据源，本地缓存只用来加速展示和支撑离线场景。

同步接口可以设计得比较简单：发送消息时调用POST接口保存，拉取历史时通过GET接口按时间增量获取。下面是一个基于fetch的前端同步示例。

async function syncMessageToServer(message) {
  await fetch('/api/messages', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(message)
  });
}
async function pullHistory(since) {
  const url = since ? '/api/messages?since=' + since : '/api/messages';
  const res = await fetch(url);
  const data = await res.json();
  return data;
}

增量同步比每次拉取全量更节省流量。客户端记录一个lastSync时间戳，首次进入页面可以传0或者不传，服务端返回全部消息；后续只返回lastSync之后新增的消息。服务端数据库需要给消息表建立created_at索引，用时间戳过滤即可。返回数据时按created_at升序排列，前端合并后避免出现顺序错乱。

离线时不能直接放弃同步。正确做法是先把消息写入本地IndexedDB，再尝试发送到服务端，失败就放入待同步队列，等网络恢复后自动重试。这样既保证了用户在当前设备能看到完整对话，又不会因为一次网络抖动丢消息。

async function sendMessage(message) {
  await localDB.addMessage(message);
  try {
    await syncMessageToServer(message);
    await localDB.markSynced(message.id);
  } catch (e) {
    await localDB.addToPendingQueue(message);
  }
}

三、IndexedDB与localStorage在缓存清理场景下的差异

很多团队一开始用localStorage存聊天记录，是因为它调用简单、读写同步。但localStorage会阻塞主线程，消息量大时页面卡顿明显，而且键值对模型不适合按时间排序或按会话查询。IndexedDB支持对象存储和索引，可以高效地按created_at字段检索历史消息，写入和读取都是异步操作，对页面性能影响小得多。

下面是一个IndexedDB的基础封装，用来创建消息表并插入数据。

const request = indexedDB.open('chat', 1);
request.onupgradeneeded = function(event) {
  const db = event.target.result;
  if (!db.objectStoreNames.contains('messages')) {
    const store = db.createObjectStore('messages', { keyPath: 'id' });
    store.createIndex('created_at', 'created_at');
  }
};
function addMessageToDB(message) {
  return new Promise((resolve, reject) => {
    const request = indexedDB.open('chat');
    request.onsuccess = function(event) {
      const db = event.target.result;
      const tx = db.transaction('messages', 'readwrite');
      tx.objectStore('messages').add(message);
      tx.oncomplete = () => resolve();
      tx.onerror = () => reject(tx.error);
    };
  });
}

不过要明确一点：IndexedDB并不会比localStorage更抗清理。它们都属于站点数据，用户清理浏览数据时都会被删除。IndexedDB的优势在于性能、容量和查询能力，而不是数据安全性。如果只把IndexedDB当作“更可靠的本地存储”，仍然无法解决用户主动清理缓存导致的历史丢失问题。

因此合理的本地缓存策略是：使用IndexedDB保存最近一段时间的消息，减少服务端请求并支持离线查看；但每次有网络时都要把新增消息同步到服务端，避免本地缓存成为唯一副本。

四、清理缓存后的恢复手段：导出、备份与冲突合并

如果用户已经在清理缓存后丢失了本地记录，并且服务端也没有同步，那只能通过应用提供的导出文件来恢复。一个实用的做法是在聊天界面加入“导出记录”按钮，把全部消息序列化为JSON文件下载到本地。用户重装系统或更换设备后，再用导入功能把文件内容写回。

下面这段代码可以把消息数组导出为JSON文件。

function exportChatHistory(messages) {
  const blob = new Blob([JSON.stringify(messages, null, 2)], { type: 'application/json' });
  const url = URL.createObjectURL(blob);
  const link = document.createElement('a');
  link.href = url;
  link.download = 'chat_history.json';
  link.click();
  URL.revokeObjectURL(url);
}

导入恢复的逻辑反过来即可：用户选择JSON文件后，用FileReader读取内容，解析后写回本地存储，并触发一次全量同步到服务端。如果之前已经存在服务端数据，导入时需要做去重，否则同一批消息会重复出现。

function importChatHistory(file) {
  const reader = new FileReader();
  reader.onload = function(e) {
    const messages = JSON.parse(e.target.result);
    localStorage.setItem('chat_history', JSON.stringify(messages));
  };
  reader.readAsText(file);
}

更完整的恢复方案是在服务端保留全量历史，用户清理缓存后重新登录即可从接口拉取。拉取逻辑要先清空本地旧缓存，再写入服务端返回的数据，避免本地残留一条已经删除的消息。对于本地尚未同步的消息，可以用message_id做判断：服务端已存在的忽略，本地独有的补上传。这个合并策略能把“清理缓存”的破坏降到最低。

最后还要提醒用户侧的操作习惯：如果应用没有登录体系，至少要在清理浏览数据前手动导出记录；如果已经有账号系统，就应该默认开启云端同步。技术手段不能完全阻止用户清理浏览器，但可以通过“本地缓存+服务端同步+可导出备份”三层结构，让对话记录不再因为一次清理就彻底消失。