靠谱，但需加防重和截断逻辑；存前先读取并初始化空数组，用Set去重（统一小写）、slice(-10)截断；按timestamp倒序排序渲染，避免key冲突；注意Android权限、iOS iCloud同步及生命周期调用时机。
uni-app 里用 uni.setStorageSync 存搜索历史靠谱吗？
靠谱，但得加防重和截断逻辑。直接无脑 push 容易把历史堆成几百条，下次读取卡顿，iOS 上甚至触发 Storage 限额警告（Exceeds quota limit）。uni.setStorageSync 是同步写，适合小量结构化数据，但别当数据库用。
常见错误现象：uni.getStorageSync 返回 undefined 或空数组（没初始化）、历史重复出现、顺序错乱（push 后没 reverse）。
- 存之前先
uni.getStorageSync('searchHistory')拿出来，为空就初始化成空数组 - 去重：用
Array.filter或Set剔掉相同关键词，注意区分大小写（建议统一转小写比对） - 截断：只保留最近 10 条，用
arr.slice(-10)，别用unshift+splice，容易漏索引
怎么让搜索历史按「最新搜索在最前」显示？
别依赖存储时的插入顺序做渲染排序——uni.setStorageSync 不保证写入时序，尤其多处并发调用时。稳妥做法是：读取后统一按时间戳或数组索引倒序，前端控制展示逻辑。
使用场景：用户点搜索框自动弹出历史列表，点击某条跳转到结果页，同时该条顶到最前。
- 每次存新记录时，加个时间戳字段：
{ keyword: '手机', timestamp: Date.now() } - 读取后用
.sort((a, b) => b.timestamp - a.timestamp)排序 - 渲染时用
v-for="(item, i) in historyList" :key="i"，别用:key="item.keyword"（重复词会冲突）
App 端真机调试时搜不到历史？检查这几个地方
不是代码问题，大概率是平台差异或权限配置导致的本地存储失效。H5 正常但 App 白屏/空数组，90% 出在这几处。
常见错误现象：uni.getStorageSync 在微信小程序正常，但 Android 打包后返回空；iOS 模拟器有数据，真机没反应。
- Android：确认
manifest.json中"permissions"包含"<uses-permission android:name='\"android.permission.WRITE_EXTERNAL_STORAGE\"/'>"</uses-permission>（虽不直接写文件，但部分厂商 ROM 对 Storage API 有额外限制） - iOS：检查是否启用了「iCloud 同步」，开启后
uni.setStorageSync的数据可能被系统清理或延迟同步，开发阶段建议关掉 - 所有平台：避免在
onLaunch外异步时机（如setTimeout）里读写，uni-app 生命周期中只有onShow或组件onLoad是稳定入口
要不要用 uni.setStorage 替代同步 API？
没必要。异步 API（uni.setStorage）对搜索历史这种轻量、即时反馈的场景反而增加不确定性：用户点了搜索，你还没写完就跳走了，历史就丢了。而且它不提升性能——本地存储本身毫秒级，异步带来的微弱并行收益远不如逻辑清晰重要。
性能影响：同步 API 在 10KB 以内几乎无感；超过 50 条带时间戳的字符串，总大小仍小于 2KB，完全在安全范围内。
- 坚持用
uni.setStorageSync和uni.getStorageSync - 如果非要异步（比如配合 loading 提示），必须加
catch并 fallback 到内存缓存，否则用户刷新页面历史就没了 - 别存对象以外的东西：不存 DOM 节点、函数、
undefined，uni.setStorageSync会静默失败且不报错
实际写的时候最容易被忽略的是「去重逻辑跑在读取之后还是写入之前」——必须在写入前处理，否则每次打开页面都重新加载一遍旧数据再覆盖，等于白做。还有就是 iOS 真机上没清缓存就换关键词测试，旧数据还在，误以为代码没生效。
