uni.setstoragesync写入失败的典型表现是数据未存入或刷新后丢失，主因是data不可序列化、key含非法字符或大小写不一致；应确保data为纯js值、key为合法字符串，并统一管理键名。
uni.setStorageSync 写入失败的典型表现
调用 uni.setStorageSync 后数据没存进去，刷新页面就丢失，或者 uni.getStorageSync 返回 undefined —— 这不是 bug，而是同步写入对参数类型和键名有硬性要求。
必须确保：
- 存储的 data 是可序列化的纯 JS 值（对象、数组、字符串、数字、布尔、null），不能含函数、Date、RegExp、undefined 或循环引用
- key 是字符串，且不能含控制字符或斜杠（如 "todo/list" 会静默失败）
- H5 端若未开启 "h5": { "useUniCloud": true }，部分平台可能限制本地存储配额，但此配置不影响 uni.setStorageSync 本身
待办清单的增删改查如何组织数据结构
别把每条待办拆成独立 key（比如 "todo_1"、"todo_2"），那样删除/遍历成本高、无法原子更新。推荐统一存为一个数组：
const todos = [
{ id: '1', title: '买牛奶', done: false, createdAt: Date.now() },
{ id: '2', title: '回邮件', done: true, createdAt: Date.now() - 3600000 }
]
操作时始终读取整个数组，修改后一次性写回：
- 新增：push 新对象，再
uni.setStorageSync('todos', todos) - 删除：用
filter剔除目标id，再写回 - 修改：用
map替换对应项，或直接findIndex+splice，再写回 - 查询：直接
uni.getStorageSync('todos') || []，无需额外判断 key 是否存在
为什么用 setStorageSync 而不是 setStorage
uni.setStorage 是异步的，回调里才能确认是否写入成功；而待办清单这类高频、小数据量操作，同步写入更可控、逻辑更直白。除非你明确需要在写入期间继续响应用户交互（比如加了 loading 动画），否则没必要引入异步流程。
但要注意：
- 同步方法在小程序主线程阻塞执行，单次写入过大（如 >1MB）可能卡 UI
- 每次写入都触发磁盘 I/O，频繁调用（如每输入一个字就存）会明显拖慢体验
- 实际项目中建议加简单防抖，例如「用户停止输入 500ms 后再保存」，而不是监听每个 input 事件立刻写
clearStorage 清空前必须确认的两件事
调用 uni.clearStorage() 会无差别清空所有 uni.setStorage* 写入的数据，包括其他功能模块（如登录态 token、用户设置）——这常被忽略。
安全做法是：
- 删除全部待办时，只清空特定 key：uni.removeStorageSync('todos')
- 若真要重置整个应用状态，先用 uni.getStorageInfoSync() 拿到 keys 列表，过滤出自己模块的 key 再逐个 removeStorageSync
- H5 端还要注意：同域下多个 uni-app 项目共用 localStorage，clearStorage 会影响其他项目
