Web Storage 封装的核心目标，是让 localStorage 的使用方式更安全、更结构化，也更贴近实际业务需求：统一数组格式存储、自动完成序列化与解析、规范 ID 类型、提供职责明确的 CRUD 方法，同时规避容量限制与安全风险，并为模块化、事件通知以及加密能力预留扩展空间。
Web Storage 封装的重点，并不是把浏览器原生能力重复实现一遍，而是让 localStorage 在实际开发中更稳定、更清晰，也更符合常见业务场景。原生 API 直接使用当然没问题，但真正容易出错的，往往正是这些细节：忘记做 JSON 序列化、没有处理空值判断、ID 类型前后不一致，最终导致数据明明存在却无法正确查询。增加一层轻量级封装，正是为了提前规避这些常见问题，提升前端存储的可维护性与可靠性。
统一数据结构管理
localStorage 只能保存字符串，但前端业务数据通常以对象数组的形式存在。因此在封装 Web Storage 时，应统一约定存储结构：所有数据都以数组形式保存在一个固定 key（如 people）下，避免多个 key 分散存储带来的管理混乱和维护成本。
- 每次读取时先判断数据是否存在，不存在则返回空数组，而不是 null 或 undefined
- 写入前自动执行 JSON.stringify，读取后自动执行 JSON.parse，让开发者始终只面向对象数据编程
- 对 id 字段进行数字类型归一化处理（person.id = id * 1），避免字符串 "1" 与数字 1 无法匹配的问题
增删改查方法职责清晰
每个 CRUD 操作方法都应只负责一项任务，参数尽量简洁，同时不暴露底层存储实现细节：
- sa ve(person)：新增一条记录，自动分配 id（或由业务侧生成），默认不校验重复数据
- deleteOne(id)：根据 id 删除单条记录，先通过 findIndex 定位，再使用 splice 移除
- update(id, person)：先查找目标索引，再整体替换对象，同时保留原有 id 字段
- findOne(id)：返回匹配到的对象，若不存在则返回 undefined，不主动抛出异常
- getAll()：返回完整数据数组，不修改原始数据内容或副本
避免常见陷阱
Web Storage 封装并不只是简单包一层方法，更重要的是主动防御 localStorage 使用过程中的典型陷阱：
- localStorage 容量有限（通常约 5–10MB），不适合做大体量数据缓存，更适用于用户偏好设置、表单草稿、轻量级列表等场景
- 不要依赖 sessionStorage 来实现“临时数据长期保留”，它在页面关闭后会失效，不适用于需要跨会话持续保存的数据场景
- 不要将敏感信息（如 token、密码）直接存入 localStorage，它本身不具备加密能力，并且同源脚本都可以访问读取
- 更新数据后必须重新调用 setItem 写回存储，不能只修改内存中的副本——这一步往往最容易被忽略
扩展性留有余地
基础版的 localStorage 封装通常已经够用，但在设计时最好预留后续升级与扩展的空间：
- 可选支持模块化 key，例如 storage.set('user:profile', {...})，便于按功能分类管理与隔离数据
- 可加入简单的变更通知机制（如发布 update 事件），方便页面视图或组件进行响应式更新
- 后续如果需要加密能力，可在 set/get 内部插入 encode/decode 流程，而不影响上层调用方式
- 兼容 TypeScript 类型定义，让 IDE 可以提示 person 的结构、方法返回值以及参数类型等信息
