Idea

背景与动机 家庭囤货是常态，但管理不善就会变成「买完忘、过期扔、重复买」的死循环。冷藏室里冻了一年的肉、柜子深处过期的调味料，是每个家庭都会遇到的场景。 市面上已有的保质期管理工具大多是 SaaS 模式，需要注册账号、连接云端。但这类工具的核心场景是个人或家庭内部使用，为了记几个日期去搭一套后端，不仅成本高，还有隐私顾虑。有没有更轻量的办法？ 答案是：纯本地微信小程序，零服务器成本。 功能设计 商品录入 扫码录入：使用 wx.scanCode 扫描商品条码，自动获取条码编号 手动回填：当扫码无法获取完整信息时，用户自行填写品名、分类、购入日期、保质期 库存看板 以列表或卡片形式展示所有商品，支持两种排序维度： 按过期时间：即将过期的排最前 按分类：同类商品聚合展示 到期提醒 首页看板高亮标记：即将过期（黄色）和已过期（红色） 小程序启动时自动检查：通过 App.onShow 或页面 onLoad 遍历所有商品，计算过期状态并展示汇总提示 条码识别演进 当前版本扫码后只拿到条码编号，需要用户手动补充品名。商业版计划接入 LLM 识别方案：拍摄商品包装 → OCR 提取文字 → LLM 结构化输出（品名、品牌、保质期），一步完成录入。 技术实现 数据模型 商品是核心实体，字段设计如下： 字段 类型 说明 code string 条码编号 (EAN-13) name string 商品名称 category string 分类（食品、日用品等） quantity number 数量 purchaseDate string 购入日期 (YYYY-MM-DD) expiryDate string 过期日期 (YYYY-MM-DD) notes string 备注 分类采用预置 + 自定义模式。预置分类包括：食品、饮品、调味品、日用品、个人护理、药品、其他。 数据持久化方案 这是整个项目最核心的技术决策。 约束条件：零云服务、零服务器成本、用户无感、数据不能轻易丢失。 微信小程序的两种本地存储 存储方式 限制 清理缓存时 清理全部数据时 wx.setStorageSync 总上限 10MB，单 key 1MB ❌ 丢失 ❌ 丢失 文件系统 (wx.env.USER_DATA_PATH) 总上限 200MB ✅ 保留 ❌ 丢失 关键区别在于：用户最常见的操作是「清理缓存」（清 Storage），而文件系统的数据不受影响。「清理全部数据」才同时清除两者，但这是用户主动销毁数据的操作，任何本地 App 都无法避免。 ...