uni-app中SQLite仅支持App端，需用@dcouldio/uni-sqlite插件并解压数据库到USER_DATA_PATH；H5用localStorage、小程序用wx.setStorageSync；收藏数据应规范建表、建索引、软删除、避免JSON存查询字段。
uni-app 里怎么用 SQLite 做收藏夹的增删查
直接上结论：uni-app 官方不支持原生 SQLite，得靠 @dcloudio/uni-sqlite 这个插件，但它只在 App 端（iOS/Android）生效，H5 和小程序完全不可用。别试了，uni.openLocation 都能跨端，但 SQLite 就是硬限制。
实操建议：
- 先确认目标平台——只有打包成 App 才能用 SQLite；H5 用
localStorage，微信小程序用wx.setStorageSync，别混着写一套逻辑去“兼容” -
@dcloudio/uni-sqlite必须通过uni.downloadFile+uni.getFileSystemManager().unzip把数据库文件解压到uni.env.USER_DATA_PATH下才能打开，不能直接读项目里带的 .db 文件 - 建表语句要手动执行，插件不自动建库建表，第一次初始化得判断
SELECT name FROM sqlite_master WHERE type='table'是否为空
收藏夹数据结构怎么设计才不容易翻车
很多人一上来就存整个商品对象 JSON 字符串进 SQLite，看着省事，后面改字段、加索引、按分类查就全卡住。
实操建议：
- 主键必须用
id INTEGER PRIMARY KEY AUTOINCREMENT，别用字符串 ID（比如后端返回的goods_id），否则排序、分页、自增逻辑全乱 - 关键查询字段单独建列：比如
type TEXT（区分商品/文章/视频）、created_time INTEGER（存毫秒时间戳，不是 Date 字符串），方便加索引和 where 查询 - 冗余一个
is_deleted INTEGER DEFAULT 0字段，软删除比真删更安全，避免误操作清空用户全部收藏 - JSON 字段只放非查询用的扩展数据，比如
extra_info TEXT，里面塞图片数组或标签列表，别在里面存标题、价格这些要搜索的字段
App 端 SQLite 查询慢？几个关键性能坑
收藏夹列表滚动卡顿、点进去加载半天，大概率不是代码写得烂，而是 SQLite 没配对。
实操建议：
- 所有
WHERE条件字段（比如type,is_deleted）必须建索引，CREATE INDEX IF NOT EXISTS idx_type_deleted ON favorites(type, is_deleted) - 别用
SELECT *，收藏夹页面只需要展示标题、缩略图、时间，就明确写SELECT id, title, thumb, created_time FROM favorites - 分页别用
LIMIT 20 OFFSET 400，OFFSET 越大越慢；换成基于游标的分页：WHERE id > ? ORDER BY id LIMIT 20，前端记上次最后一条的id - 事务批量插入时用
BEGIN IMMEDIATE而不是默认的BEGIN DEFERRED，减少锁等待
跨端收藏状态同步不了？别硬扛 SQLite
用户在 App 里收藏了，在微信小程序里看不到——这不是 bug，是 SQLite 根本没在小程序里跑起来。强行用同一套代码，只会让 H5 和小程序走 localStorage 分支，App 走 SQLite 分支，数据天然割裂。
实操建议：
- 业务层抽象一个
FavoriteService类，内部根据uni.getSystemInfoSync().platform切换底层存储：App 走uniSQLite，微信小程序走wx.setStorageSync，H5 走localStorage - 如果真需要多端数据一致，就得上云数据库（如 uniCloud 的
collection），本地 SQLite 只当临时缓存，每次启动拉一次云端收藏列表，本地只做离线兜底 - 别在 onShow 里无脑 reload 全量收藏列表，加个时间戳判断：如果本地数据更新时间距今
最麻烦的其实是“删除收藏后，其他设备怎么知道”。SQLite 本地删了，别的端根本收不到通知——这事只能靠定时轮询或者消息推送，别指望数据库自己同步。
