Web Storage在低版本浏览器中不可靠，需运行时实测读写能力而非仅检测对象存在，按indexedDB→localStorage→sessionStorage→内存/cookie降级，并配合HTML/CSS兼容保障功能可用。
Web Storage（localStorage 和 sessionStorage）在低版本浏览器中容易报错或完全不可用，不是简单加个 try-catch 就能解决的。关键在于提前检测、安全降级、避开限制场景，而不是等出错再补救。
先确认是否真支持，别只看文档
很多开发者以为 IE8+ 就天然支持 localStorage，但实际中常因“保护模式开启”“隐私设置严格”或“InPrivate 模式”导致 setItem 直接抛 QUOTA_EXCEEDED_ERR 或 SecurityError。正确做法是运行时验证，而非仅检查对象是否存在：
- 用随机 key 写入再删除，验证读写能力（ngStorage 的
isStorageSupported就是这么做的） - 对 Safari 私有模式、iOS “阻止 Cookie” 开启状态、IE 安全区域等特殊场景，必须走这步实测
- 不要依赖
typeof localStorage !== 'undefined'—— Safari 私有模式下它存在，但调用会失败
IE 下的访问权限错误处理
IE（尤其是 IE10 及更早）在启用保护模式或受限安全区域时，访问 localStorage 会直接抛 SCRIPT5: Access is denied。这不是代码问题，而是浏览器策略限制：
- 捕获异常后，应立即切换到备用方案（如内存缓存、sessionStorage，或降级为 cookie 存储小数据）
- 避免让整个应用因 storage 失败而中断 —— ngStorage 做法值得参考：返回一个空壳对象，所有方法都设为
angular.noop - 若业务强依赖持久化，可引导用户关闭 IE 的“启用保护模式”，或提示改用 sessionStorage（它在多数 IE 场景下更稳定）
旧版浏览器兜底方案设计
当检测到 Web Storage 不可用时，不能丢弃功能，而要提供轻量级替代：
- 内存模拟：用普通 JS 对象暂存数据，页面刷新即丢失，但保证逻辑不崩
-
cookie 回退：对小于 4KB 的键值对，用
document.cookie+ 编码封装，兼容 IE6 起 -
userData（仅 IE）：IE5–IE9 支持的专有行为，需用
element.addBehavior('#default#userData')，现已基本淘汰，仅作极端兼容备选 - 统一接口层：封装
storage.set()/storage.get()，内部自动路由到可用后端，上层无感知
CSS/HTML 配套兼容不掉链子
Storage 兼容不只是 JS 层的事。如果页面本身在低版本浏览器里渲染异常，用户根本点不到触发存储的按钮：
- IE8–IE9 不识别
<section><header>等语义化标签，需引入html5shiv - 避免用 Flex/Grid 布局控制关键操作区域 —— 若 storage UI 因样式失效而不可见，再好的降级也没用
- 用百分比或 float 实现基础布局，确保按钮、表单控件在 IE8 下仍可交互
