菜谱是长期生活数据，不能按临时服务对待。

\n
Mealie 看起来是一个轻量菜谱应用，但真正用起来后，它保存的是家庭长期生活数据：常做的菜、改过的配方、购物清单、图片、分类、家庭成员习惯。它不像临时测试容器，删掉再建也无所谓。部署之前先把数据目录、图片、数据库和成员权限想清楚，后面才适合长期使用。

菜谱数据会慢慢变重要

刚开始录入几道菜时，Mealie 只是好玩。用上几个月后，它会变成家庭记忆的一部分：某道菜谁爱吃，哪个配方少放糖，节假日菜单怎么安排，常买食材有哪些。这些信息散在聊天记录和纸条里很容易丢，集中到 Mealie 后就应该按正式数据保护。

我会先设计分类和标签，不急着一次性录入很多。比如家常菜、烘焙、早餐、儿童餐、节日菜单可以分开，标签用于口味、耗时、是否适合提前准备。分类太随意，后面搜索会变差；分类太复杂，家人又懒得用。菜谱工具最终要服务日常做饭，不是服务整理癖。

图片和数据库要一起看

Mealie 里的菜谱图片不是装饰。很多时候，家人靠图片判断是不是那道熟悉的菜。上传图片、菜谱字段、用户、计划和设置通常都落在应用数据目录或数据库里。只备份文本导出，不备份图片，恢复后会缺很多直观信息；只备份图片，不备份数据库，也无法恢复完整菜谱关系。

部署时要确认 Mealie 使用的是内置数据库还是外部数据库。小规模家庭使用可以先用默认方式，但无论哪种，都要知道数据库文件或数据库服务在哪里。备份策略要覆盖数据目录、数据库和 compose 配置。恢复演练时随机打开几道带图菜谱，确认图片、步骤、份量和标签都还在。

导入要小批量验证

从网页、笔记或旧工具导入菜谱时，不要一次性导入几百条。不同来源的字段质量差别很大，标题、图片、步骤、时间、份量可能都需要修。先导入十几条代表性菜谱，检查搜索、分类、图片显示和移动端编辑体验，再决定是否批量迁移。

如果家人也参与录入，最好先约定简单规则：标题怎么写，图片拍成什么样，步骤里是否写火候和时间，标签怎么选。规则不用复杂，但要一致。否则同一道菜可能出现多个版本，搜索时也很难判断哪个才是常用版本。

家庭成员权限要分开

Mealie 的账号权限不应该所有人都是管理员。管理员负责备份、用户、系统设置；常用成员可以创建和编辑菜谱；只偶尔查看的人给浏览权限就够了。家庭服务最常见的误操作不是恶意破坏，而是有人点错删除、批量修改或导入了重复内容。

对于共享设备，比如厨房平板，我更愿意使用权限较低的账号。它只需要查看菜谱和购物清单，不需要管理系统。这样即使设备被孩子乱点，影响也有限。权限分级不是把家人当外人，而是让服务更耐用。

升级前后检查具体内容

Mealie 升级前先备份数据目录和数据库，记录当前版本。升级后不要只看登录页，要打开带图菜谱、搜索一个标签、编辑一条测试菜谱、检查购物清单和家庭成员账号。图片路径、数据库迁移和权限变化是比较容易被忽略的地方。

日常维护可以很轻：每月确认备份成功，偶尔导出一份菜谱，清理重复条目，检查图片是否还能显示。Mealie 的目标不是把做饭流程复杂化，而是让家里常用菜谱变得可查、可传承、可恢复。只要围绕这个目标部署，它就是一个很适合 HomeLab 的生活型服务。

购物清单功能也要控制预期。它适合把菜谱和采购联系起来，但不一定要替代所有家庭备忘工具。真正有用的是周末做饭前能快速生成食材清单，做完后能把配方调整写回菜谱。不要为了功能完整去维护大量没人看的字段，常用信息能稳定留下来就够了。

图片存储要注意体积。手机随手拍的照片可能很大，菜谱图片如果不压缩，几年后也会变成明显容量。可以在导入时控制图片尺寸，或者定期检查 data 目录增长。图片清晰到能识别成品和关键步骤即可，不需要保留每张原始大图。

如果家里有老人或孩子使用，页面入口要尽量简单。把 Mealie 放在清晰的家庭服务分组里，账号保持低权限，常用菜谱通过收藏或分类固定好。自托管服务最好的状态，是维护者知道它怎么恢复，使用者不用知道它怎么部署。

我还会定期导出一份通用格式的菜谱副本。数据库备份适合完整恢复，通用导出适合换工具或临时查看。两种备份目的不同，最好都保留。这样即使未来不继续使用 Mealie，家里的菜谱也不会被困在某个单一应用里。

厨房使用场景还要考虑离线兜底。至少把常用菜谱定期导出或打印几份，网络故障时不会影响做饭。自托管服务可以提高便利性，但不应该让一顿饭完全依赖服务器在线。