浏览器对本地缓存的访问控制核心取决于同源策略（SOP），而非运行方式本身；普通HTTP/HTTPS网页下LocalStorage和IndexedDB完全可用且按协议、域名、端口三要素严格隔离，file://协议因无明确源被禁用，无痕模式下数据仅限当前窗口且退出即销毁，SSR/静态站点需在客户端JS执行后才可安全访问。
浏览器对本地缓存的访问控制，核心取决于“同源策略”（Same-Origin Policy），而非运行方式本身。所谓“四种运行方式”通常指：普通网页、本地文件（file://协议）、私密/无痕模式、以及服务端渲染（SSR）或静态站点生成（如通过 dist 目录直接双击打开）等离线加载场景。这些方式会显著影响 LocalStorage 和 IndexedDB 的可用性与隔离性，但不是因为它们改变了 API 行为，而是改变了浏览器判定“源”的逻辑和安全上下文。
普通 HTTP/HTTPS 网页（如 https://example.com）
这是标准、最稳定的使用环境：
- LocalStorage 和 IndexedDB 均完全可用，容量通常为 5–10MB（LocalStorage）和数十至数百 MB（IndexedDB，依浏览器而定）
- 数据按完整源隔离：协议 + 域名 + 端口三者必须完全一致；
https://a.com与http://a.com不互通，https://a.com:8080与https://a.com也不互通 - 标签页间共享数据（同源下所有 tab 共用同一份 LocalStorage / 同一 IndexedDB 数据库实例）
- 刷新、关闭再打开标签页，数据均保留
本地文件协议（file://）
双击 HTML 文件或用 VS Code Live Server 以外的方式直接打开本地文件，会触发严格限制：
- 绝大多数现代浏览器（Chrome、Edge、Firefox）默认禁用
localStorage和indexedDB，调用setItem或open会抛出SecurityError - 原因：file:// 没有明确的“源”，无法满足同源策略基本前提，被视为高风险上下文
- 绕过方法有限且不推荐：Chrome 启动时加
--unsafely-treat-insecure-origin-as-secure="file://"参数（仅开发调试），或改用本地 HTTP 服务（如npx serve） - 结论：不要在
file://下设计依赖本地存储的功能
无痕/隐私模式（Incognito / Private Browsing）
该模式下缓存行为被刻意隔离，退出即销毁：
- LocalStorage 和 IndexedDB 均可用，但数据生命周期仅限当前无痕窗口
- 关闭所有无痕窗口后，所有写入的数据（包括数据库结构、索引、记录）将被彻底清除
- 与普通窗口完全隔离：无痕窗口里存的
theme=dark，不会影响主窗口的设置；反之亦然 - 部分浏览器（如 Safari）在隐私模式下甚至限制 IndexedDB 的初始创建，首次
open可能静默失败
SSR/静态站点（如 Next.js 输出的 dist 目录，或 Vite 预构建产物）
这类应用本质仍是普通网页，但首次渲染发生在服务端或构建时，需注意客户端激活时机：
- LocalStorage / IndexedDB 在客户端 JS 执行后才可访问，服务端环境（Node.js）中二者均不存在，
typeof localStorage为'undefined' - 若在 React/Vue 组件的
useEffect或onMounted外提前读取，会报错；务必做存在性判断：if (typeof localStorage !== 'undefined') { ... } - 静态资源托管在 CDN 或 GitHub Pages 时，只要通过
https://访问，就享有完整缓存能力；但若托管在不支持 CORS 的旧平台，IndexedDB 的某些跨域资源加载可能受影响（极少见） - 注意：构建工具（如 Webpack）不会自动 polyfill 这些 API，兼容性需自行保障（如 IE11 需降级方案）
