迁移旧项目到Composer需分四步：先初始化composer.json并手动引入现有依赖；再通过require vendor/autoload.php切换自动加载，配置PSR-4；接着替换硬编码路径为命名空间调用或服务封装；最后清理旧目录和加载语句，规范composer.json与.gitignore。
将非Composer管理的旧项目迁移到Composer，核心是分阶段替换依赖管理方式，避免一次性大改导致项目崩溃。重点在于先让Composer共存，再逐步接管，最后清理旧逻辑。
第一步：初始化Composer并引入现有依赖
在项目根目录运行 composer init，按提示填写包名、描述等基础信息（可暂用占位值）。关键不是填得完美，而是生成 composer.json 文件。接着，手动将当前项目实际使用的第三方库（如 PHPMailer、Monolog、Smarty 等）以对应版本号写入 require 字段。不确定版本？查 vendor/ 或 lib/ 目录下的文件注释、README 或 Git 提交记录。示例：
"phpmailer/phpmailer": "^6.8""monolog/monolog": "2.9.*""smarty/smarty": "~4.3.0"
运行 composer install，确认依赖被正确下载到 vendor/。此时不急着删旧文件，只验证新路径能加载。
第二步：统一自动加载机制
旧项目通常靠一堆 require_once 或自定义 __autoload 加载类。迁移关键一步是切换到 Composer 的自动加载。在入口文件（如 index.php 或 bootstrap.php）顶部添加：
require __DIR__ . '/vendor/autoload.php';
然后逐个检查旧的 require/require_once 语句：如果加载的是 Composer 已管理的包，直接删除；如果是项目自己的类，把它们归入 PSR-4 命名空间，并在 composer.json 中配置 autoload：
"autoload": { "psr-4": { "App\\": "src/" } }- 执行
composer dump-autoload生效
确保所有类可通过命名空间 new 出来，不再依赖物理路径包含。
第三步：逐步替换硬编码路径和手动加载逻辑
搜索项目中所有类似 require 'lib/some-class.php'、include '../includes/config.php' 这类路径引用。对第三方库，一律改为命名空间调用；对配置或工具函数，考虑封装为服务类或迁入 config/ + src/，用 DI 或静态工厂替代全局包含。常见场景处理：
- 数据库连接文件 → 改为
Config::get('database')或注入 PDO 实例 - 公共函数文件（
functions.php）→ 拆成工具类，如StringUtils::slug() - 模板引擎初始化 → 用 Composer 加载后，通过工厂创建实例，而非 include + new Smarty()
每次改完跑一遍核心流程（登录、列表、提交），确保功能未退化。
第四步：清理与收尾
确认所有功能稳定运行至少一个完整业务周期（如一天或一次发布流程）后，才开始清理：
- 删除旧的
lib/、includes/、pear/等第三方目录（保留一份备份） - 移除所有残留的
require_once第三方库语句 - 把
composer.json中的minimum-stability和prefer-stable设为合理值 - 添加
.gitignore规则，排除/vendor/和/composer.lock（若团队协作，应提交 lock 文件）
至此，项目已由 Composer 统一管理依赖、加载和扩展，后续新增组件只需 composer require，维护成本显著降低。
