首先初始化Composer并配置PSR-4自动加载，逐步迁移旧代码至命名空间，通过引入vendor/autoload.php统一入口，在不破坏原有逻辑的前提下用Composer管理新依赖，替换手动引入文件，兼容全局变量和函数，并借助测试保障迁移安全，实现渐进式升级。
在一个遗留的非Composer项目中引入Composer，关键在于渐进式迁移，避免一次性重构成导致风险。目标是让项目既能继续运行，又能逐步享受依赖管理、自动加载等现代PHP开发带来的便利。
1. 初始化Composer并隔离新旧代码
在项目根目录运行 composer init，创建 composer.json 文件。初期不需要定义太多依赖，只需配置好自动加载机制。
建议从 PSR-4 自动加载 开始，为新代码或可迁移的模块定义命名空间：
{
"autoload": {
"psr-4": {
"App\\": "src/"
}
}
}
然后执行 composer dump-autoload 生成自动加载文件。这样你可以在项目中引入 vendor/autoload.php，新类就能被自动加载，而老代码仍可通过原有方式包含文件。
2. 引入 vendor/autoload.php 入口统一化
找到项目的入口文件（如 index.php、bootstrap.php），加入以下代码：
这一步不会影响现有功能，但为后续引入 Composer 包打下基础。确保所有请求都经过这个入口，以便自动加载生效。
3. 逐步替换手动 include/require 为自动加载
识别老代码中的全局函数、工具类或可封装的模块，逐步将其移到 src/ 目录下，并加上命名空间。
例如，一个老的工具文件：
// src/Helper/FileHelper.php
之后就可以用 App\Helper\FileHelper::upload() 调用，不再需要手动 require。
4. 用 Composer 管理新依赖，逐步替代老旧库
当需要添加新功能时，优先使用 Composer 安装标准库（如 Guzzle、Monolog），而不是手动下载放入 lib/ 或 includes/ 目录。
对于已存在的第三方库，检查是否有 Composer 版本。如果有，移除手动文件，通过 composer require vendor/package 安装。
若某些库没有发布到 Packagist，可用 仓库类型 引入私有 Git 仓库：
"repositories": [
{
"type": "vcs",
"url": "https://github.com/your-company/legacy-lib"
}
]
5. 处理全局变量和函数的兼容问题
遗留项目常依赖全局变量（如 $db, $config）或全局函数。可在 Composer 的自动加载中加入对函数文件的支持：
"autoload": {
"psr-4": { "App\\": "src/" },
"files": ["helpers.php", "config.php"]
}
这样这些文件会在每次请求时自动载入，平滑过渡。
6. 持续集成与测试保障迁移安全
如果项目有测试（单元或功能测试），在引入 Composer 后确保测试仍能通过。如果没有，建议先补基础测试，再进行重构。
每次执行 composer update 或修改自动加载后，验证核心流程是否正常。
