LocalStorage 在低端 Android 设备上可能不稳定，需用带写入验证的探测函数检测；常见问题包括容量缩水、同步阻塞、隐私模式失效；应结合 try...catch、降级缓存及服务端校验兜底。
LocalStorage 在绝大多数现代移动端浏览器中支持良好，但在部分低端 Android 设备（尤其是 Android 4.0–4.3 系统、WebView 内核陈旧的定制 ROM 或第三方浏览器）上，存在读写异常、容量限制更严、甚至完全不可用的情况。关键不在于“是否支持”，而在于“是否稳定可用”。
检测 LocalStorage 是否真正可用
仅用 'localStorage' in window 判断不够——某些低端设备会返回 true，但实际调用 setItem 时抛错（如 QUOTA_EXCEEDED_ERR 或 SecurityError），或写入后立即读不到。
推荐使用带写入验证的探测函数：
function isLocalStorageUsable() {
try {
const key = '__ls_test__';
localStorage.setItem(key, '1');
if (localStorage.getItem(key) === '1') {
localStorage.removeItem(key);
return true;
}
localStorage.removeItem(key);
} catch (e) {
// 捕获 QuotaExceededError、SecurityError、TypeError 等
}
return false;
}
低端设备常见问题与规避策略
• 实际可用容量远低于 5MB：部分 Android 4.x WebView 实际有效容量仅 2–3MB，且碎片化严重；建议单次写入控制在 100KB 以内，避免累积写入触发静默截断。
• 同步写入阻塞 UI：低端 CPU + 单线程 JS 容易卡顿；对非关键数据（如用户偏好、埋点缓存），可考虑节流写入或延迟提交（如 onbeforeunload 时保存）。
• 私有模式/无痕窗口下失效：某些低端浏览器在隐私模式下直接禁用 LocalStorage 且不报错；务必配合上述可用性检测，降级到内存对象缓存（const fallbackStore = {}）。
兼容性兜底方案建议
• 优先使用 try...catch 包裹所有 setItem/getItem 调用，避免因存储失败导致业务逻辑中断。
• 对重要数据（如登录态 token），不要单独依赖 LocalStorage；应与 Cookie 或服务端 session 结合校验。
• 可引入轻量级封装库（如 store.js），它自动降级到 userData（IE6–7）、globalStorage（旧 Firefox）或内存存储，对低端 Android 兼容更稳健。
