Composer无运行时沙箱，依赖隔离靠composer.lock与PHP环境双重控制；vendor目录共享导致静态状态污染，需通过分隔autoload、隔离测试依赖、platform模拟等手段实现逻辑隔离。
共享依赖的测试环境无法隔离，本质是 Composer 没有运行时沙箱 —— 你得靠 composer install 的输入（composer.lock）和执行环境（PHP 版本、扩展、平台配置）双重控制，而不是指望它自动“分身”。
为什么 vendor 目录一改全项目都受影响
Composer 安装依赖时，默认把所有包解压到统一的 vendor/ 目录下，类自动加载走的是同一个 autoload.php。哪怕两个子模块逻辑上独立，只要它们 require 同一个包（比如 monolog/monolog），就共用同一份代码实例和静态状态。测试中一个 test 修改了 MonologLogger::$defaultLevel，另一个 test 就可能被意外污染。
常见错误现象包括：
- 本地跑单个 test 通过，
vendor/bin/phpunit全量运行时失败 - CI 上偶发失败，本地无法复现（因执行顺序或 autoload 加载顺序差异）
- mock 对象在不同 test 间残留，
$this->createMock()返回的实例被意外复用
用 composer.lock + --no-dev 构建最小化测试镜像
生产环境依赖和测试依赖本就不该混用。CI 中构建测试环境时，别直接 composer install，而是分两步走：
- 先用
composer install --no-dev --prefer-dist安装运行时依赖，生成干净的vendor/ - 再单独为测试创建隔离空间：新建目录
tests/vendor，在其中执行composer require --dev phpunit/phpunit:^10.5并配置"autoload-dev": { "psr-4": { "Tests\": "tests/" } } - 测试启动时显式引入
tests/vendor/autoload.php，而非项目根目录的vendor/autoload.php
这样 Tests* 类只加载测试专用依赖，核心业务代码仍走生产级 vendor/，彼此类加载器互不干扰。注意：必须确保 tests/vendor/autoload.php 中的 autoloader 没有注册到全局 spl_autoload_register() 链里，否则仍会泄漏。
多版本 PHP 下验证共享依赖兼容性
当多个项目共享一组底层包（如自研的 company/utils），而它们分别跑在 PHP 7.4、8.1、8.3 上时，不能只靠“本地 PHP 版本能跑通”来判断。必须让 Composer 在解析依赖时就模拟目标环境：
- 在
composer.json的config.platform中硬编码目标 PHP 版本，例如："php": "7.4.33" - 配合 Docker 或
phpbrew切换真实 PHP 环境，在每个版本中执行：composer install --no-dev && vendor/bin/phpunit - 特别注意：如果共享包用了 PHP 8.0+ 的联合类型（
string|int），但在platform.php设为7.4后composer install仍成功 —— 这说明该包未声明php依赖约束，属于隐式不兼容，需立刻补上"require": { "php": "^7.4 || ^8.0" }
测试中动态切换依赖版本的临时方案
要验证“升级 guzzlehttp/guzzle 到 7.9 是否破坏现有 HTTP client 封装”，又不想污染主 composer.lock？不用新建项目，用 Composer 的局部覆盖能力：
- 复制当前
composer.lock为composer.lock.guzzle79 - 执行：
composer require guzzlehttp/guzzle:^7.9 --no-update，再composer update guzzlehttp/guzzle --lock，它只会重写 lock 文件中 guzzle 相关行 - 测试前运行：
cp composer.lock.guzzle79 composer.lock && composer install --no-dev - 测试完立刻
git checkout -- composer.lock回退 —— 整个过程不碰 git 工作区，也不影响其他开发者
这个技巧的关键在于：Composer 的 install 完全信任 composer.lock 内容，它不校验“这个版本是否真能从 packagist 下载”，只确保 vendor 目录与 lock 文件一致。所以只要 lock 文件合法，就能快速构造出任意依赖组合的测试快照。
真正容易被忽略的点是：很多团队把 composer.lock 当成“安装结果快照”，却忘了它是“可编辑的契约文件”。只要理解它的结构（尤其是 packages 和 packages-dev 分区），就能在不破坏协作前提下，对共享依赖做精准、可逆、可复现的测试干预。
