在旧php项目中引入composer需确保PHP≥7.2、启用curl等扩展，通过composer.json配置autoload（psr-4+files）、入口引入vendor/autoload.php，并逐步迁移依赖、分离执行逻辑，最终用composer install –no-dev部署。
直接在旧PHP项目中引入Composer不难，关键是让现有代码能和Composer生态共存，同时避免破坏原有逻辑。核心是两件事：一是让自动加载兼容老代码，二是逐步把依赖迁移到vendor目录。
确认PHP版本和基础环境
Composer要求PHP ≥ 7.2（推荐≥7.4），先运行php -v检查。如果版本过低，需先升级PHP或选择兼容的Composer版本（如Composer 1.x支持PHP 5.6+，但已停止维护，不建议新接入）。确保系统已安装cURL、Openssl、Zip扩展——多数旧项目依赖这些处理远程包和解压。
初始化composer.json并配置自动加载
在项目根目录执行composer init，按提示填写包名、描述等（可全留空，后续手动编辑）。生成的composer.json里重点改两项：
- autoload：用
psr-4映射新写的类，用files包含旧全局函数文件（如"files": ["includes/functions.php", "config/database.php"]） - autoload-dev：为测试文件单独配置，不影响生产环境
然后运行composer dump-autoload生成自动加载映射。之后在入口文件（如index.php）顶部加上require 'vendor/autoload.php';，确保它在任何旧代码执行前被引入。
立即学习“PHP免费学习笔记（深入）”；
逐步迁移第三方库
不要一次性替换所有外部库。优先处理有明确命名空间、且旧项目只用其核心功能的包（比如monolog/monolog替代自写日志类）。操作步骤：
- 用
composer require vendor/package安装（例如composer require guzzlehttp/guzzle） - 删掉原来的手动
include或require语句 - 将旧调用方式改为Composer推荐用法（如
new GuzzleHttpClient()代替自封装的HttpRequest类） - 对暂无法替换的库（如强耦合的自研SDK），先用
repositories字段临时指向本地路径或git仓库，再慢慢解耦
处理全局常量与启动逻辑冲突
很多旧项目在config.php或init.php里定义常量、连接数据库、初始化session。这类代码不能直接放进files自动加载（会重复执行）。解决办法：
- 把纯定义型内容（如
define('app_ENV', 'prod')）保留在files中 - 把执行型逻辑（如
mysqli_connect()、session_start()）拆出来，放在入口文件中require 'vendor/autoload.php'之后手动调用 - 用
classmap加载旧的无命名空间类（如"classmap": ["lib/", "classes/"]），Composer会扫描并生成对应映射
改造完成后，用composer install --no-dev部署到生产环境，确保vendor目录不包含开发依赖。后续新增功能尽量用Composer管理，老代码保持不动，自然过渡。