indexeddb不能替代离线存储，仅负责结构化数据持久化；完整离线需配合cache api或service worker缓存静态资源，二者分工明确、不可错配。
IndexedDB 不能单独“替代”离线存储，它只是离线存储体系中负责结构化数据持久化的那一环。真正实现完整离线能力，必须配合 Cache API（或 Service Worker + caches）一起用。
IndexedDB 不处理网络资源缓存
常见错误现象：页面离线后白屏、CSS/JS 加载失败、图片不显示——这和 IndexedDB 无关，是静态资源没被缓存。
原因在于：IndexedDB 只存你主动写入的结构化数据（比如用户草稿、表单记录、离线消息），它不拦截 fetch 请求，也不缓存 /main.css、/api/posts 这类 URL 资源。
正确做法：
- 用
Service Worker拦截请求，把 HTML/CSS/JS/图片等写入caches.open("static-v1") - 把用户生成的数据（如编辑中的文档）存进
IndexedDB - 离线时，Service Worker 先查
cache.match()返回资源，再由前端 JS 从IndexedDB读取内容渲染
Cache API 和 IndexedDB 的分工不能颠倒
使用场景错配会导致性能问题或功能失效：
- 拿
caches存用户上传的Blob或大文件？可以，但无法按字段查询、不支持事务、删除只能整 cache 清空 - 拿
IndexedDB存index.html或logo.png？技术上可行，但绕过浏览器原生缓存机制，丢失Cache-Control控制力，且每次读都要走异步事务，渲染阻塞风险高 - API 响应该存哪？小而固定（如配置项）可进
caches；带分页、需筛选、含用户权限逻辑的响应，应解析后存IndexedDB并建索引
IndexedDB 初始化失败常被误判为“离线不可用”
错误现象：Uncaught DOMException: Failed to execute 'open' on 'IDBFactory': access to the Indexed Database API is not allowed in this context
这不是离线问题，而是运行环境限制：
- 非
https://或localhost下，部分浏览器（如 Chrome）直接禁用IndexedDB - 私密模式下，Safari 默认禁用
IndexedDB（返回null，不抛异常） -
iframe且sandbox属性不含allow-same-origin时，IndexedDB不可用
建议在调用 indexedDB.open() 前加兜底判断：
if (!window.indexedDB) {
console.error("IndexedDB not supported");
return;
}
if (window.location.protocol !== "https:" && window.location.hostname !== "localhost") {
console.warn("IndexedDB may be blocked in non-secure contexts");
}
事务失败不会自动重试，但离线场景下必须考虑重入
IndexedDB 的事务是“尽力而为”，不是最终一致。典型坑点：
- 用户离线时调用
db.transaction().objectStore().add()，如果数据库已关闭或版本冲突，会直接 reject，不会排队等待联网 - 没有内置队列或重试机制——你得自己用
localStorage记录待同步操作，上线后再批量提交 - 多个标签页同时写同一 store？
versionchange事件会触发，老页面的 DB 实例自动 close，但你的代码若没监听，后续add()就报InvalidStateError
复杂点在于：离线期间产生的数据冲突（比如两个标签页都改了同一条笔记），IndexedDB 本身不提供合并策略，这部分逻辑必须由业务层控制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
