代码备份之后，还差多少才能恢复一个项目

一个目录无法回答所有恢复问题

整理多个服务时，很容易把文件复制完成当成迁移完成。但同一个目录里可能混着源码、构建结果、运行依赖、业务文件与历史备份。文件都在，并不代表能重新编译；程序能启动，也不代表旧业务能够恢复。

项目迁移记录因此按服务列出不同层次：有哪些源码，线上使用什么发布物，依赖如何安装，服务如何启动，配置与数据由哪里提供。清单的作用，是把含糊的完成变成可以逐项回答的问题。

源码与发布物要分别说明

有些服务在服务器上只找到构建产物，后来从本机历史工作区补齐了前端工程；另一些服务只找到发布运行时，未发现可编译源码。两种情况不能都写成源码迁移完成。

保留发布物可以帮助维持运行，找到源码和锁定依赖则关系到后续维护。若二者来自不同时间，还要进一步核对源码能否构建出预期行为，不能仅凭目录名称认定版本一致。

空数据启动是明确的边界

迁移仓库排除了业务数据库、上传清单、设备原始日志以及真实配置和证书。这样的仓库能够描述如何启动一个空环境，却不包含原有业务历史。恢复历史需要单独的数据迁移与校验流程。

这不是文字上的区别。账号、权限和业务记录缺失时，健康检查可能仍然正常。若验收只看到服务存活，就会把运行环境准备完成误当成业务恢复完成。

验证应当接近实际使用

相关实施记录还要求核对实际生效的发布版本、本地源码、构建结果与页面交互，并保留未完成事项。对于持续接收数据的服务，回滚同样需要考虑新数据，不能简单用旧数据库覆盖正在增长的内容。

一次可靠的交接至少应该说清楚：哪些部分能重新构建，哪些只能按发布物运行，哪些配置需要另行提供，哪些数据尚未恢复。每一项结论都应有对应的检查，而不是共享一句测试通过。

本文依据迁移清单和实施记录总结，没有重新执行新服务器恢复演练。因此它记录的是边界与方法，不能作为完整灾难恢复已通过的证明。对我来说，迁移工作最有价值的产物之一，就是这份能够诚实说明缺口的清单。