先保留硬编码文件，通过Composer安装依赖并共存运行，逐步切换调用至新版本，验证无误后删除旧文件并优化自动加载，确保平滑过渡。
直接删除硬编码文件再引入 Composer 依赖容易引发路径、命名空间或自动加载问题。要平滑替换，需分步骤操作，确保项目功能不受影响。
1. 确认当前库的版本和命名空间
查看硬编码库的源码，记录其版本号、类的命名空间和文件结构。比如是否遵循 PSR-4 或 PSR-0 标准，是否有自己的 autoloader。这有助于后续配置 Composer 自动加载时保持兼容。
- 检查是否存在 autoload.php 或类似引导文件
- 确认主类名和调用方式（如 new Library\Main()）
- 记录当前 include/require 的路径逻辑
2. 使用 Composer 安装等效依赖
在 composer.json 中添加对应库的包。优先选择官方发布包，若无，则可使用 VCS 方式引入 Git 仓库：
"repositories": [ { "type": "vcs", "url": "https://github.com/user/library-repo" } ], "require": { "vendor/library": "1.2.*" }运行 composer install，确保新依赖正确下载。
3. 并行共存，逐步切换调用
暂时保留原硬编码文件，让旧代码继续工作。修改自动加载或入口文件，优先使用 Composer 加载类。可通过临时别名或条件加载验证新旧版本行为一致：
- 修改 require 路径指向 Composer 版本
- 使用 class_alias 兼容旧类名（如有冲突）
- 逐个文件替换实例化语句，观察日志和测试结果
4. 清理与验证
确认所有调用都走 Composer 后，删除原硬编码目录。执行完整测试，包括单元测试和集成流程。同时更新文档和 .gitignore，防止误提交 vendor 文件（如有必要）。
- 运行 composer dump-autoload -o 优化自动加载
- 检查生产环境部署脚本是否包含 composer install 步骤
- 通知团队成员变更情况
基本上就这些。关键是不急于删除旧代码，先让新依赖跑起来，再安全切换。整个过程对线上服务无感，才算真正“优雅”替换。
