Composer无法让新旧框架依赖直接共存，因autoload机制限制同一命名空间只能由一个包实现；真实场景需通过隔离命名空间、replace欺骗、--with-all-dependencies升级依赖链及PSR-4分路径加载等方式逐步过渡。
Composer 能不能同时装新旧框架的依赖
不能直接共存，Composer 的 autoload 和类加载机制决定了同一命名空间只能由一个包提供实现。比如 Laravel 9 和 Symfony 6 都用 SymfonyComponentHttpFoundationRequest，但版本不兼容时，Composer 安装会报冲突，或者运行时报 Class not found 或方法不存在。
真实场景里，你不是在“共存”，而是在“过渡”：一边跑旧代码，一边接入新框架组件，靠隔离 + 逐步替换推进。
- Composer 本身不支持“按目录启用不同框架版本”，
composer.json中的require是全局生效的 - 想让旧模块继续用 Laravel 8、新模块用 Laravel 10？必须拆成独立可加载的逻辑单元，不能指望 Composer 自动路由
- 常见错误现象：
Declaration of AppHttpControllersX::handle() must be compatible with IlluminateRoutingController::handle()——这是签名不一致，本质是混用了不同框架版本的基类
用 replace + provide 欺骗 Composer 解决冲突
当旧项目依赖某个包 A v1.2，但新框架强制要求 A v2.5，而你又不能立刻升级整个项目时，可以用 replace 告诉 Composer：“我已经有了这个包的兼容实现”，跳过安装冲突版本。
例如 Laravel 8 项目要引入 Laravel 10 的 laravel/serializable-closure（它被 10 默认 require），但旧版 illuminate/support 不兼容，可以这样写：
"replace": {
"laravel/serializable-closure": "*"
},
"require": {
"laravel/serializable-closure": "^1.3"
}
关键点：
-
replace后面的包名必须和冲突包完全一致（包括大小写），版本号写*表示全部替代 - 必须紧接着用
require显式指定你实际要装的兼容版本，否则 Composer 会彻底忽略它 - 这个技巧只解决“安装通过”，不解决运行时行为差异——比如新包用了 PHP 8.1 特性，而你还在用 PHP 7.4，照样崩
用 Composer 的 --with-all-dependencies 安装混合版本
默认 composer update foo/bar 只更新该包及其直系依赖，容易因间接依赖版本锁死导致失败。迁移中常遇到“我想升 symfony/http-foundation 到 6.x，但它被 laravel/framework v8 锁在 5.4”。
这时要用 --with-all-dependencies 强制连带升级整条依赖链：
composer update symfony/http-foundation --with-all-dependencies
但要注意：
- 它可能把
laravel/framework也推到 v9+，如果你没准备好，就直接破掉旧路由或中间件逻辑 - 执行前务必
git status确认工作区干净，并先跑一遍测试，因为这个命令会改composer.lock中大量条目 - 某些包（如
phpunit/phpunit）在不同框架主版本间 ABI 不兼容，强行带入会导致Class 'PHPUnitFrameworkTestCase' not found
用 PSR-4 自动加载隔离新旧代码路径
Composer 不管你代码怎么组织，只管自动加载规则。真正的共存靠的是把新旧模块放在不同命名空间 + 不同目录，再用 autoload 分开映射。
比如旧代码在 app/ 下走 App 命名空间，新模块放在 src/Next/ 下走 Next 命名空间：
"autoload": {
"psr-4": {
"App\": "app/",
"Next\": "src/Next/"
}
}
然后运行 composer dump-autoload 生效。这样做之后：
- 你可以用
NextHttpRequest而不干扰原有的IlluminateHttpRequest - 两个命名空间下的同名类（如
Request）互不影响，因为自动加载器按前缀查路径 - 容易踩的坑：别漏掉
composer dump-autoload -o（优化模式），否则开发时类找不到；上线前必须加-o，否则性能差一倍不止
最麻烦的从来不是 Composer 命令怎么敲，而是搞清哪些类已经被新框架重写、哪些接口签名变了、哪些配置键名废了——这些信息散落在各版本的 upgrade guide 里，得一行行比对，不能靠 composer update 自动兜底。
