优先用 uni.setstoragesync，因 app 端搜索历史需强即时写入，避免切后台时丢失；去重应 filter 删除旧项后 unshift 新项再截取前 10 条；读取必须在 onload 中并判空默认 []；纯 uni api 存储不受 ios 隐私开关影响。
uni-app 里搜索历史用 uni.setStorageSync 还是 uni.setStorage
优先用 uni.setStorageSync，App 端搜索历史属于强即时写入场景，异步写入可能在页面跳转或进程后台化时丢失数据。
原因很简单：App 启动快、切后台频繁，uni.setStorage 的回调时机不可控，而历史记录一旦没存上，用户点开搜索框就“清空了”，体验断层。同步 API 虽然阻塞主线程，但搜索历史一般只有几条字符串，写入耗时可忽略。
-
uni.setStorageSync('searchHistory', historyList)是稳妥选择 - 如果非要异步（比如批量存大量数据），必须加
try/catch并 fallback 到同步写入 - 注意 iOS App 后台运行约 3 秒后会被系统挂起，此时
uni.setStorage回调大概率不执行
搜索历史怎么去重 + 保持最新顺序
不能简单 push 后再 Array.from(new Set()) —— 那会打乱时间顺序；也不能每次存都全量覆盖，太浪费 IO。
推荐做法是：读出原数组 → 删除已存在的旧项 → unshift 插入新项 → 截取前 10 条。
const history = uni.getStorageSync('searchHistory') || []
const keyword = 'uni-app'
// 删除重复项（保留最新一次出现的位置）
const filtered = history.filter(item => item !== keyword)
// 插入到最前面
filtered.unshift(keyword)
// 限制最多 10 条
const final = filtered.slice(0, 10)
uni.setStorageSync('searchHistory', final)
- 用
filter而不是indexOf + splice，避免修改原数组引发意外引用问题 - 不要用
includes判断再决定是否插入——它无法区分“刚搜过”和“本该保留的旧记录” - 截取操作必须放在最后，否则可能把刚插进去的新词给截掉
App 端冷启动时搜索框不显示历史？检查 onLoad 时机
常见错误是把读取逻辑写在 data() 里或 created 钩子中，但 App 端 onLoad 才真正保证页面 DOM 和存储环境就绪。
尤其 Android 上，created 可能早于 uni 存储模块初始化完成，导致读出来是 null 或空数组。
- 历史列表必须在
onLoad或onShow中读取并赋值给data字段 - 如果用了 Composition API（
setup），需配合onLoad生命周期钩子，不能只靠onMounted - 首次打开 App 时，
uni.getStorageSync返回undefined是正常现象，要主动判空并给默认值[]
Android 和 iOS 对本地存储路径/权限有差异吗
没有。uni-app 的 uni.setStorageSync 在 App 端底层统一走平台原生文件存储（Android 用 getFilesDir()，iOS 用 NSDocumentDirectory），不需要额外申请权限，也不受 iCloud 同步影响。
但要注意一个隐藏坑：iOS 14+ 后，如果用户开启“App 跟踪透明度”或关闭“定位与隐私→本地网络”，不会影响 uni.setStorage，但某些自定义原生插件可能会误判为沙盒受限，导致存储失败。
- 纯
uniAPI 不受系统级隐私开关影响 - 如果用了第三方 SDK（如友盟、极光）封装的存储逻辑，得单独验证其兼容性
- 真机调试时发现存不上，先用
console.log(uni.getStorageInfoSync())看实际容量和 keys，别急着怀疑代码
