localStorage 持久存储且跨会话，sessionStorage 仅限当前标签页会话；二者均同源、仅支持字符串、有容量限制、同步阻塞，存对象需 JSON 序列化，不安全存敏感信息，推荐封装容错读写并优先评估数据必要性。
localStorage 和 sessionStorage 有什么区别？
两者都属于 Web Storage API，但生命周期和作用域不同：localStorage 持久保存，关闭浏览器也不丢失；sessionStorage 仅在当前标签页会话期间有效，关闭标签即清空。
它们都只能存字符串，存对象必须先 JSON.stringify()，读取时再 JSON.parse()。不支持直接存函数、undefined、Symbol 或 Date 对象（会转成空字符串或 "Invalid Date"）。
- 同源限制：协议 + 域名 + 端口完全一致才可访问
- 容量限制：通常为 5–10MB，但各浏览器不一，超出会抛
QuotaExceededError - 同步阻塞：读写都在主线程，大量数据可能卡 UI
如何安全地使用 localStorage.setItem() 和 getItem()？
直接调用 localStorage.setItem(key, value) 很容易出错——比如 value 是对象却没序列化，或 key 为空字符串，或浏览器禁用本地存储（如无痕模式下 Safari 默认禁用）。
推荐封装一层容错逻辑：
立即学习“Java免费学习笔记（深入）”；
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
function safeSetItem(key, value) {
try {
if (typeof window === 'undefined') return;
const str = JSON.stringify(value);
localStorage.setItem(key, str);
} catch (e) {
if (e.name === 'SecurityError' || e.name === 'QuotaExceededError') {
console.warn(`localStorage write failed for key "${key}":`, e.message);
}
}
}
function safeGetItem(key, defaultValue = null) {
try {
const str = localStorage.getItem(key);
return str ? JSON.parse(str) : defaultValue;
} catch (e) {
console.warn(`localStorage parse failed for key "${key}":`, e.message);
return defaultValue;
}
}
注意：localStorage.getItem() 返回 null 而非 undefined，判断存在性别用 == null 或 === null，避免误判 false、0、"" 等假值。
localStorage 有哪些典型误用场景？
很多人把它当“前端数据库”用，结果踩坑不断：
- 存敏感信息（如 token、用户密码）——
localStorage可被 XSS 直接读取，绝不该存认证凭据 - 高频写入（如每秒更新计数器）——触发磁盘 I/O，影响性能，应合并或节流
- 未监听
storage事件就期望跨标签同步——它只在**其他标签页**修改时触发，本页修改不会触发自身事件 - 依赖
localStorage.length判断是否为空——某些浏览器（如旧版 iOS Safari）返回不准确，建议用Object.keys(localStorage).length
有没有比 localStorage 更现代的替代方案？
有，但要看场景：
- 需要事务、索引、大量结构化数据 → 用
IndexedDB（复杂但强大） - 临时缓存、轻量状态 →
sessionStorage更安全（关闭即销毁） - 服务端已登录，只需前端维持 UI 状态 →
useState+useEffect（React）或ref持久化更可控 - 需加密存储 → 不要自己实现 AES，改用
Web Crypto API的subtle.encrypt()，且密钥不能硬编码
真正关键的不是“用哪个”，而是想清楚：这个数据是否真的需要跨页面保留？是否会被恶意脚本读取？有没有更小的作用域能覆盖需求？这些问题比选 API 更重要。
