升级自部署 xypass 前后，应该检查什么

容器显示“running”只能证明进程启动了，不能证明账户、密文、附件和恢复链路都正常。自部署升级前后各留出十几分钟做检查，远比出现数据问题后临时猜测可靠。

升级前先留下可恢复的现场

确认最近一次备份包含 PostgreSQL、一致的附件密文、必要配置和恢复密钥，并查看备份任务的完成时间。重要升级前最好在隔离目录做一次恢复演练，而不是只相信“备份成功”的状态。

记录当前应用版本、镜像摘要、数据库迁移版本和容器状态。阅读目标版本的发布说明，特别留意数据库迁移、环境变量和持久化目录变化。生产 .env、数据库目录和附件目录不应因为重建容器而被删除。

如果多人正在使用，先安排维护窗口并等待同步完成。请勿在升级过程中继续编辑条目，也不要让两套不同版本同时写入同一个数据库。

按照当前版本的部署文档拉取代码、检查环境并执行生产脚本，让迁移任务先完成，再切换应用容器。只更新官网或 Web 静态资源时，可以使用已有的 Web-only 发布流程，避免无关服务重启。

不要把“重新创建容器”和“删除持久化数据”混为一谈。容器可以替换，数据库和附件挂载必须继续指向原来的宿主机路径。

先检查健康接口和容器日志，再用测试账户完成一次完整流程：登录账户、按需输入 MFA、解锁保险库、读取旧条目、创建测试条目并同步到第二台设备。随后查看、上传和下载一个测试附件，确认历史数据与新写入都正常。

再检查 Admin 的认证配置、账号数量、Vault 数量和存储状态，确认备份任务仍能访问数据库与附件目录。若公网经过反向代理，还要验证 HTTPS、上传大小限制和真实客户端地址没有被新配置覆盖。

应用启动失败时，先保留日志、迁移输出和当前数据副本。只有确认旧镜像与数据库结构兼容，或拥有升级前的一致恢复点时，才执行回退。直接让旧程序连接已经完成新迁移的数据库，可能把可恢复故障变成数据损坏。