收藏菜谱不难，做饭前找到合适的一道菜却不一定容易。链接散在聊天与书签里，份量没有改成家里需要的数量，买菜时又把几个菜的配料分别抄一遍。
Mealie 可以整理自己的菜谱，安排菜单并建立购物清单。放在 VPS 上，家人用手机也能访问同一个入口。真正有帮助的是把经常做的菜整理成可靠记录，而不是把所有看过的链接都导入。
先选三道熟悉的菜，完整记录配料、步骤和自己的调整，再用它们排一次菜单。软件是否适合家庭使用，从这次小试用就能看出来。
家庭小规模使用，可以先采用 SQLite
Mealie提供 Docker 部署，并支持 SQLite 与 PostgreSQL。对于写入并发较少的小环境，SQLite 能减少一套数据库服务。需要更多并发或特定功能时，再按官方说明选择 PostgreSQL。
SQLite 数据应放在合适的本地存储。官方特别提醒，不要将这一方案的数据库直接放在网络文件系统上，否则可能遇到锁或数据问题。VPS 上挂载的远端存储不应未经核对就当成普通本地盘。
菜谱图片、数据库与应用状态放在数据卷中。保存菜谱网址不等于保存菜谱内容，原网页删除或改版后，自己维护的结构化记录才有价值。
按当前镜像配置一个独立实例
VPS 已安装 Docker 和 Compose。以下配置参考SQLite 安装文档，采用该文档当前列出的 v3.28.0。安装时应重新核对发布信息与迁移说明，不把本文版本当成永远最新。
mkdir -p ~/mealie
cd ~/mealie
services:
mealie:
image: ghcr.io/mealie-recipes/mealie:v3.28.0
ports:
- "127.0.0.1:9925:9000"
environment:
ALLOW_SIGNUP: "false"
PUID: "1000"
PGID: "1000"
TZ: Asia/Shanghai
BASE_URL: https://recipes.example.com
volumes:
- mealie-data:/app/data
deploy:
resources:
limits:
memory: 1000M
restart: unless-stopped
volumes:
mealie-data:
域名和用户编号按实际环境修改。示例的内存限制来自官方配置，不是对所有 VPS 的规格保证；检查自己使用的 Compose 是否实际应用限制，再观察启动、导入和日常使用。不要只看 YAML 里写了数字就认为资源问题已经解决。
docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 mealie
ssh -L 19925:127.0.0.1:9925 user@your-server
打开本机 http://127.0.0.1:19925，先在私人入口完成初始化。当前安装检查表列出的默认账号是 [email protected]、密码 MyPassword。登录后立即调整账号与密码，再创建家人的账号，不能把演示凭据留到正式使用。
域名可用以后，再邀请家人
用已有反向代理把 recipes.example.com 转到本机9925端口，提供 HTTPS，并将 BASE_URL 设置为实际地址。域名只是示例，换地址以后也要重新应用容器环境。
公开根地址会影响分享和邮件中的链接。用另一台设备打开完整菜谱链接，检查是否能够访问，而不是仅在管理员浏览器里点击。家人没有 SSH 隧道，不会使用本机19925端口。
SMTP 配置用于邀请和密码相关邮件，按所用发送服务填写。配置保存以后发一封测试邀请，从收件人设备完成流程。邮件能发出去，还要确认链接、域名和账号操作都正常。
关闭开放注册不等于所有菜谱自动保持私人。检查家庭、群组、用户权限和公开分享的具体设置，拿未登录窗口验证哪些内容能看到。打算分享一份菜谱时，也核对链接里是否只包含希望分享的内容。
导入网页只是整理的第一步
菜谱网页如果提供可解析结构，Mealie 可以帮助导入。网站结构、访问限制和内容形式不同，导入结果可能不完整。先看菜名、份数、原料、步骤和图片，不要看到标题出现就认为整份记录正确。
短视频中的做法、图片文字或作者随手写的段落，未必能自动成为结构化菜谱。手工整理反而可能更清楚：把材料与步骤分开，把“适量”保留为原表达，自己实际调整的部分另写备注。
配料中数量和单位尤其值得检查。两勺、一杯和若干克不能随意互换，原资料没有换算依据时，不要为了方便购物猜一个精确重量。份量缩放以后也应核对调味与烹饪时间，并不是所有步骤都能等比例变化。
先整理家里常做、已经知道怎样完成的菜。记录自己实际做过的调整时写明属于个人备注，别把未经尝试的建议包装成成功经验。菜谱库保持可查、有来源，也更容易与家人讨论变化。
一周菜单不要排得比现实复杂
从几个工作日晚餐开始，而不是一次规划三十天。考虑已有食材、做饭时间和剩余饭菜，再安排菜谱。菜单是辅助计划，临时调整以后也要更新购物清单，避免仍买旧计划里的材料。
同一种食材在不同菜谱里可能使用不同名字或单位。整理成统一、能识别的表达，有助于合并采购；但不应为了让系统合并，就把不同原料强行当成一样。
购物清单生成后，先与家里已有库存对照。厨房里已经有盐和油，不必每次都当成需要重新购买。应采购的数量也以实际使用为准，不能直接把算法计算值当成已核验需求。
手机操作要走一次真实路径：打开菜单、查看一份菜谱、加入或调整清单、在采购时标记完成。若家人只需要看步骤，却必须经过很多管理页面，调整组织方式比增加新功能更有帮助。
图片与手工记录也需要恢复
Mealie 提供备份与恢复功能，使用前按当前版本文档核对包含内容。导出以后，保存到独立位置，在测试实例恢复，检查菜谱、图片和相关状态。只备份原始网页 URL，会丢掉后来补充的配料与备注。
示例使用具名卷，实际卷名带 Compose 项目前缀。可以通过容器挂载信息查找，不要凭目录名称猜宿主机路径。维护期间完整备份持久化卷时，先停止应用写入，再用合适工具归档，避免运行中的 SQLite 文件与其他状态不一致。
docker compose ps -q mealie
得到容器 ID 后，用 docker inspect 查看 Mounts，确认映射到 /app/data 的卷。检查输出时不必分享完整环境变量，那里可能包含邮件凭据。
重新部署配置时也要确认仍连接原来的卷。改了项目目录或项目名，可能创建一份新卷，看起来像菜谱全部消失。先核对挂载，不要在空实例里重新导入，造成两套记录。
菜谱与采购清单对不上，先查表达方式
同一道菜导入后，原料可能包含“葱”“小葱”和“葱花”几种描述。它们有时指同一食材的不同处理阶段，有时并不相同。整理时依据实际做法判断，不能只为了清单合并把文字机械替换。
数量也是如此。一个菜写两根，另一个写十克，软件即使能分组也不一定知道正确换算。采购前把这些条目人工核对，日常常用的材料可以逐渐整理统一。没有依据的单位换算保留为备注，避免把估计写成精确数据。
购物列表应与当天真正要做的菜一致。菜谱从两人份改成四人份以后，检查列表是否按自己的操作更新；临时取消一道菜，再核对它的独有材料是否还在。自动生成能减少抄写，不会自动知道家里改变了计划。
剩余食材也可以成为菜单的起点。先看冰箱里已经有的材料，再找适合的菜谱，按现实安排而不是为了填满软件的日历。家庭成员参与采购时，约定清单何时更新，避免双方在不同时间各自复制一份。
从手机端验收邀请与访问权限
管理员登录状态下打开分享链接，常会误以为任何人都能访问。用未登录窗口和家庭普通账户分别查看，确认公开与私人内容的区别。对外分享一份菜谱时，也检查说明和个人备注是否适合公开。
邀请邮件收到以后，完成链接点击与新账号登录，不只确认邮箱里有一封消息。链接地址不对、密码设置失败和账号权限不足，是不同问题，应各自排查。让家人实际走一次，往往比自己在后台检查更容易发现阻塞。
手机界面里长步骤和大图片会影响阅读。整理菜谱时将步骤按操作顺序写清，不需要把来源网页的背景故事全部搬过来。站在灶台旁边能直接看懂，比库里有很多条目更有用。
把恢复测试放进升级流程
固定版本的意义，是给维护者留时间阅读变更。升级前保存应用备份和原镜像标识，更新后检查登录、菜谱详情、导入、菜单与购物清单。数据库迁移执行以后，简单换回旧镜像不一定能回退整个状态。
家人账号能登录，管理员却打不开某个功能时，按具体权限和日志检查；导入网页失败时，先确认目标是否仍存在、服务器是否能访问。不要让所有问题都变成“升级一下试试”。
用一段时间后，删除不再有用途的测试菜谱，整理重复来源和模糊备注。保留能在做饭时直接理解的步骤，而不是建立一个数量很多却不愿打开的收藏库。菜谱、菜单与采购能顺着同一条日常路径使用，Mealie 才会留下来。