没有部署文档时，如何在 Debian 12 还原混合运行时系统

先还原运行前提，再讨论业务

接管只有编译产物、历史 SQL 和零散脚本的系统时，最容易犯的错误是直接启动服务。缺少部署文档意味着数据库、端口、常驻进程、反向代理和构建工具之间的关系都不明确，任何“先跑起来再说”的改动都可能覆盖仅存的线索。

第一阶段应保持只读：列出文件类型、配置入口、SQL、进程脚本和二进制依赖，再建立可以验证的运行时清单。

数据库初始化文件不完整时，可以对照 PHP 查询、ORM 模型和历史 SQL，整理实际访问的表、字段、默认值和索引。对于已经存在非空数据的环境，任何补齐操作都要先备份，再用最小迁移完成，不能直接覆盖导入。

两套系统共享服务器时，数据库、账号和站点目录保持独立，避免修复一个系统时影响另一个系统。

Debian 基座可能同时需要 Nginx、PHP-FPM、MySQL、Node.js/PM2、Python/Flask、.NET Runtime 和 Android 工具链。每个组件都记录版本、路径、服务方式、监听端口、运行用户和健康检查，形成一张明确矩阵。

Web：Nginx、PHP 版本、PHP-FPM Socket、open_basedir 与上传权限。
实时服务：Node.js/PM2、WebSocket 端口、Nginx Upgrade 代理和环境变量。
辅助服务：Python/Flask、.NET Runtime、独立端口和日志位置。
构建链：JDK、Android SDK、Build Tools、Apktool、APKEditor、apksigner、zipalign、aapt/aapt2。

WebSocket 进程可能已经监听端口，但 Nginx 没有配置 Upgrade 代理；后台配置可能仍指向旧域名；上传目录可能存在但 PHP-FPM 用户没有权限。这些问题都需要从浏览器、代理、进程和文件系统四层逐一验证。

HTTPS、登录和 101 握手是基础检查，随后还要验证双向消息、后台任务、上传和真实构建入口。

Apktool 可以编译、zipalign 可以对齐、apksigner 可以完成 v2/v3 验签，只能证明工具链基本可用；它不等于后台真实任务已经通过。PHP-FPM 的 disable_functions、环境变量、目录权限或进程启动策略，都可能让业务任务在进入工具链前失败。

恢复报告必须明确区分“依赖已安装”“工具链冒烟通过”和“真实业务构建已验收”，避免把阶段性进展写成完整完成。

没有部署文档时，工程能力体现在如何从代码访问痕迹反推数据库、从二进制依赖还原运行时、从端口和代理恢复服务链，并为每个判断保留验证证据。系统最终不仅要能运行，还要让下一位维护者知道它为什么能运行。