localStorage仅支持字符串值，存对象或数组须显式JSON序列化，否则取值时崩溃；IndexedDB才是真正的离线数据库，需通过onupgradeneeded建库建表，所有操作必须在transaction内执行。
localStorage 适合存小量结构简单、不常更新的键值对；IndexedDB 才是真正能支撑离线应用、批量读写、索引查询的浏览器本地数据库——别用 localStorage 存数组或对象后直接 JSON.stringify 就以为万事大吉，那只是把问题推迟到取值时崩溃。
localStorage 的正确写法与典型翻车点
它只接受字符串作为值，setItem 会静默调用 toString()，导致对象变成 [object Object]，数组变成逗号拼接字符串。存之前必须显式序列化，取之后必须显式反序列化。
常见错误现象：
- 存了
{ user: { id: 1, name: "Alice" } }，取出来是"[object Object]" - 存了
[1, 2, 3]，取出来是"1,2,3"，再JSON.parse报错 - 存了含
undefined或函数的对象，JSON.stringify直接丢掉字段，还原后数据不全
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 始终用
JSON.stringify存，用JSON.parse取，且加try/catch - 避免存超大字符串（Chrome 限制约 5–10MB，但实际超过 2MB 就可能卡主线程）
- 不要依赖
localStorage做状态同步——它不触发跨 tab 的storage事件（除非是其他 tab 修改）
const saveUser = (user) => {
try {
localStorage.setItem('user', JSON.stringify(user));
} catch (e) {
console.error('localStorage write failed:', e);
}
};
const loadUser = () => {
const raw = localStorage.getItem('user');
if (!raw) return null;
try {
return JSON.parse(raw);
} catch (e) {
console.error('localStorage parse failed:', e);
return null;
}
};
IndexedDB 创建数据库与对象仓库的最小可行步骤
IndexedDB 不是“打开即用”，必须先发请求建库、等 onupgradeneeded，再在回调里定义 objectStore 和 index。跳过这步，后续所有 add/get 都会报 InvalidStateError。
关键点：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
indexedDB.open第二个参数是版本号，**必须是整数**，升级时改它才会触发onupgradeneeded - 在
onupgradeneeded中用db.createObjectStore创建仓库，不能在onsuccess里做 - 首次打开或版本升级时，
onupgradeneeded必定执行；已存在且版本未变，则跳过
const openDB = () => {
return new Promise((resolve, reject) => {
const req = indexedDB.open('myAppDB', 1);
req.onerror = () => reject(req.error);
req.onsuccess = () => resolve(req.result);
req.onupgradeneeded = (event) => {
const db = event.target.result;
if (!db.objectStoreNames.contains('users')) {
const store = db.createObjectStore('users', { keyPath: 'id' });
store.createIndex('by_email', 'email', { unique: true });
}
};
});
};
用 transaction 确保读写安全：为什么不能直接调 store.get
IndexedDB 所有操作都必须包裹在 transaction 内，哪怕只是读一个值。直接访问 objectStore 属性会报 InvalidStateError: Cannot access object store outside a transaction。
使用场景差异：
-
readonly事务支持并发读，适合列表页加载 -
readwrite事务自动排队，适合表单提交、状态更新 - 事务生命周期 = 回调函数执行完 + 所有请求完成，**不是**函数返回就结束
容易踩的坑：
- 在
transaction.oncomplete外访问结果——此时数据可能还没写入磁盘 - 重复使用同一个事务对象跨异步操作（如 await 后再用），事务早已关闭
- 忘记指定
mode，默认是readonly，写操作直接失败
const getUserById = async (db, id) => {
return new Promise((resolve, reject) => {
const tx = db.transaction('users', 'readonly');
const store = tx.objectStore('users');
const req = store.get(id);
req.onsuccess = () => resolve(req.result);
req.onerror = () => reject(req.error);
});
};
localStorage 与 IndexedDB 混用时的数据一致性陷阱
有人用 localStorage 缓存 IndexedDB 查询结果来提速，结果改了 DB 却忘了清 localStorage，用户看到的是旧数据。这不是“缓存策略”，是 bug 温床。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 避免双写——要么全走 IndexedDB，要么只用 localStorage 存 UI 状态（如折叠面板开关）这类与服务端无关的数据
- 如果非要缓存，把清理逻辑绑定到 IndexedDB transaction 的
oncomplete，而不是靠定时器或手动清除 - 注意 IndexedDB 是异步、localStorage 是同步——混用时别假设“刚存完 DB 就能从 localStorage 读到最新值”
最常被忽略的一点：IndexedDB 的 keyPath 和 index 一旦设错，升级时删库重建是唯一干净解法；而 localStorage 没有 schema，坏数据只会让 JSON.parse 在某次启动时突然失败——前者问题暴露早，后者问题藏得深。
