家里的牛奶什么时候过期？药到底吃没吃？下班路上想起要买洗衣液，到了超市却又忘了。
这些事情每一件都不大，但每天反复出现，就很消耗精力。
我试过备忘录、聊天软件置顶，甚至在冰箱上贴便签。结果往往是：记录散落在不同地方，真正需要的时候反而找不到。于是我产生了一个很直接的想法：能不能做一个足够简单的 App，把物品保质期、购物清单和用药计划放在一起？
这就是我开发「安心管家（SafeNest）」的起点。
现在它已经上架华为应用市场。如果你也有类似的生活困扰，可以先下载体验：
点击前往华为应用市场下载「安心管家」
目前是 1.0.1 版本。它不要求注册或登录，主要数据保存在本机，离线也能使用。我希望它是一款安静、轻量、打开就能记的生活工具，而不是又一个向用户索要手机号、推送广告和制造焦虑的 App。
我到底做了哪些功能？ 第一项是物品保质期管理。
我可以记录食品、调料、日化用品、护肤品和药品的到期日期、数量、存放位置以及提前提醒天数。App 会自动计算物品处于正常、临期、过期还是已用完状态，还支持按名称搜索、分类筛选和到期时间排序。
一个我自己很喜欢的小细节是：某件东西用完后，可以直接加入购物清单。生活中的“库存管理”和“补货”本来就是连续动作，我不想让用户再手动录入一次。
第二项是购物清单。
除了名称，还能记录数量、单位、分类和优先级。买到后随手勾选，全部采购完再一键清理。我刻意没有把它做成复杂的任务管理器，因为站在超市货架前，用户需要的是一眼看清和一次点完。
第三项是用药计划。
我可以按药品记录每次剂量、每日服用时间、起止日期，以及饭前、饭后等信息。首页会汇总今天的待服任务，完成后可以勾选，也可以暂停或恢复某项计划。
这里必须特别说明：这个功能只用于记录和提醒，不提供任何医疗或诊断建议，具体服用方式仍应以医生建议或药品说明书为准。
首页则把今日待服、临期物品和待买商品集中到一个页面。我的目标不是堆功能，而是让人打开 App 的几秒内就知道：今天最需要关注什么。
为什么选择芋道 uniapp？ 这款 App 使用的是芋道 uniapp 项目 框架，核心技术栈包括 UniApp、Vue 3、TypeScript、Pinia 、Vite 和 SCSS，并适配 HarmonyOS App。
我选择这套方案，主要是因为它已经把很多工程化能力组织好了：页面与组件约定、状态管理、持久化、自动导入、样式方案和构建配置都比较完整。对于个人开发者来说，能把更多时间花在产品逻辑上，而不是从零拼装脚手架，是很重要的。
但“框架搭起来了”不等于“鸿蒙端可以直接无脑运行”。真正让我花时间的，恰恰是跨端框架、构建插件与鸿蒙运行时之间的兼容问题。
最折磨我的问题：H5 正常，鸿蒙端却卡在启动阶段 这是整个开发过程中最值得记录的一次踩坑。
当时页面逻辑在常规环境下没有明显异常，但打到鸿蒙端后，应用会出现卡死或首次渲染无法正常完成的情况。它不像普通业务错误那样直接告诉我某一行代码错了，更像是应用已经启动，却迟迟进不到可交互状态。
我最初也怀疑过页面逻辑、Pinia 持久化和资源加载，后来结合构建配置逐步缩小范围，问题最终指向两类兼容因素：依赖版本组合和只适用于常规 uni-app 页面的 Vite 插件。
我的处理分成三步。
第一步，把 DCloud 相关依赖统一升级到同一批次的鸿蒙版本。
我将 @dcloudio/uni-app、@dcloudio/uni-app-harmony、@dcloudio/vite-plugin-uni 等包统一到 3.0.0-alpha-5020120260710001。这里最重要的不是“越新越好”，而是同一生态的核心包尽量保持版本对齐。混用不同批次的编译器、运行时和 Vite 插件，会把兼容问题变得非常隐蔽。
第二步，锁定关键 Vue 版本。
我把 Vue 和 @vue/runtime-core 从带 ^ 的范围版本改为精确的 3.4.21。个人项目经常会因为重新安装依赖，悄悄拿到一个满足范围但行为不同的小版本。调试跨端问题时，如果依赖树还在漂移，每一次重装都可能让排查结论失效。
第三步，在鸿蒙构建时关闭两个会改写页面结构的插件。
项目原本启用了页面优化插件和额外根节点插件。它们在普通平台上有价值，但鸿蒙原生页面由官方运行时托管，首次渲染阶段再次改写页面结构，可能与原生页面生命周期发生冲突。
所以我根据 UNI_PLATFORM 做了条件加载：当目标平台是 app-harmony 时，不启用 Optimization 和 UniKuRoot；其他平台仍保留原来的优化能力。
修改后，鸿蒙端的卡死问题得到解决，我也把版本从 1.0.0 更新到了 1.0.1。
这次经历给我的教训是：遇到 uni-app 鸿蒙端启动卡死，不要只盯着业务页面。还应该依次检查：
DCloud 核心依赖是否属于同一版本批次； Vue 与运行时版本是否一致、是否会因范围符号自动漂移； Vite 插件是否修改了页面结构、根节点或生命周期； 某个构建优化是否真的适用于 app-harmony； 锁文件、实际安装版本和构建工具使用的版本是否一致。 另一个容易忽略的坑：鸿蒙图标不是“放一张 Logo”就结束了 上架前我还处理了一个看起来很小、实际非常影响第一印象的问题：应用图标的前景图和背景图。
最初我把同一张 Logo 同时作为 foreground 和 background。这样做省事，但在鸿蒙的图标体系下，裁切、缩放和不同形状适配的效果并不理想。
后来我把资源拆成独立的前景图 logobegin.png 和背景图 logobg.png，启动窗口图标则继续使用完整 Logo。这样系统在不同设备和图标蒙版下组合时，主体位置和背景填充会更稳定。
如果你也在做 uni-app 鸿蒙应用，建议一开始就按“前景层、背景层、启动图”分别准备素材。图标不是最后随手补一下的装饰，它是用户在应用市场和桌面上看到产品的第一秒。
更早的一次项目经历，让我重新理解了“数据已经删了，页面为什么还在” 翻看 Git 记录，我之前做校园工具时还遇到过三个典型问题：校园信息无法编辑、GPA 学期无法重命名，以及清除所有数据后，课程仍显示在页面上，必须重进应用才刷新。
第三个问题尤其典型：存储层的数据已经清除，不代表内存中的响应式状态也同步清除了。
如果页面渲染依赖的是 Store 中的数组，只清 uni 本地存储，而没有同时重置 Store，当前页面当然还会拿旧状态继续渲染。重新进入应用后之所以“恢复正常”，只是因为启动流程重新从空存储初始化了一次，并不代表清理逻辑本身正确。
这段经历直接影响了安心管家的设计。我把物品、购物、用药拆成独立的 Pinia Store，并通过持久化插件保存；增删改、标记已购和标记已服都先更新响应式状态，再由持久化层同步。页面通过 computed 派生待办数量、临期列表和今日用药任务，尽量保持单一数据源。
对我来说，这也是从“功能能跑”走向“状态变化能立刻、正确地反馈到界面”的一次升级。
为什么首版坚持本地存储、不做登录？ 做产品时很容易产生一种冲动：账号体系、云同步、家庭共享、消息推送都想第一版完成。
但我最后选择克制。
安心管家记录的是很日常、也比较私人的信息。首版不依赖业务后端，不要求注册登录，主要数据保存在当前设备中，也不会主动上传用户记录的生活数据。它因此可以离线使用，启动路径也更短。
代价同样存在：卸载应用、清理应用数据或更换设备，可能造成当前本地数据丢失。数据导入导出、多设备同步和家庭成员共享，是我希望在后续版本逐步补上的能力。
写在最后：我想邀请你做第一批真实用户 从一个生活中的小麻烦，到用芋道 uniapp 完成功能，再到解决鸿蒙端卡死、图标适配和上架问题，这个 1.0.1 版本并不完美，但它已经是我自己愿意每天打开使用的工具。
如果你家里也经常有食物、药品或日用品忘记保质期，或者想把购物清单和用药计划放在一个更安静的工具里，欢迎下载试试：
华为应用市场： 安心管家（SafeNest）下载页面
如果它确实帮你少忘了一件东西、少浪费了一件物品，希望你能回到华为应用市场给我一个评分。评分和真实评论会直接影响一款新 App 能否被更多人看到，对个人开发者非常重要。
如果使用中遇到问题，也欢迎在评论区告诉我：你的手机型号、系统版本、操作步骤，以及你原本希望它怎么工作。我会认真看每一条反馈，并继续更新。
也想听听大家的选择：下一版你最希望我先做哪一个——本地数据导入导出、家庭成员共享、日历视图，还是更完善的系统通知？
