如何确保多个项目独立运行，通过Composer完全解除全局与局部依赖的关联？

本文共计992个文字，预计阅读时间需要4分钟。

全局和局部依赖混杂，不是能否共存的问题，而是何时会突然崩塌的问题。真正分隔的关键不在安装方式，而在执行路径、自动加载器归属以及是否有显式控制输入口。

为什么which phpunit返回的不是项目里那个

PATH 环境变量从左到右匹配，而系统默认把 ~/.composer/vendor/bin（或 Windows 的 %APPDATA%\Composer\vendor\bin）放在前面。哪怕你项目里 vendor/bin/phpunit 是 v10.5，只要全局装了 v9.6，phpunit 命令就大概率调到旧版。

• 验证方法：运行 which phpunit，再用 head -n 3 $(which phpunit) 看脚本头是否指向全局 autoload.php
• 临时解决：进项目目录后，直接跑 ./vendor/bin/phpunit —— 不依赖 PATH，不绕弯子
• CI/CD 脚本中必须写全路径，不能只写 phpunit；否则某次全局更新后，测试就静默降级

项目内 require-dev 工具为何还可能被全局 autoload 干扰

根本矛盾在于：CLI 工具二进制文件是 PHP 脚本，它自己决定加载哪个 autoload.php。有些工具（如旧版 PHPStan）的 bin 文件硬编码了 require __DIR__.'/../vendor/autoload.php'，但没限定是项目还是全局的 vendor。

• 现象：项目里 composer require-dev phpstan/phpstan:^1.12，却报 Class not found: PHPStan\Analyser\NodeScopeResolver
• 原因：你执行的是全局 phpstan，它加载的是全局 autoload.php，根本没读项目 vendor/autoload.php
• 解法：一律用 ./vendor/bin/phpstan；或者删掉全局版本，改用 cgr phpstan/phpstan 隔离安装

composer install --no-dev 为什么有时仍加载了 dev 包

--no-dev 只跳过安装，不清理已存在的 autoload 映射或残留文件。尤其在容器构建或 PHAR 打包场景下，漏掉一两个文件就足以让 Class not found 在生产环境复现。

• 检查点：部署后进容器执行 ls vendor/ | grep phpunit，有输出即失败
• 关键动作：必须确认 vendor/composer/autoload_dev.php 不存在；它比 composer.lock 里的 packages-dev 更危险
• Dockerfile 中应显式写：RUN composer install --no-dev --optimize-autoloader --no-scripts && rm -f vendor/composer/autoload_dev.php

该不该把多个工具的 vendor/ 合并到根目录

不该。每个 vendor/ 对应一个独立的 autoload.php 和命名空间映射规则。合并后，require __DIR__.'/vendor/autoload.php' 会失效，且无法通过简单调整路径修复——因为根 autoload 不知道 tools/mailchimp/src/ 应该映射到什么命名空间。

• 风险远超收益：Tool A 依赖 guzzlehttp/guzzle:^7.5，Tool B 锁死 ^6.5，合并后必有一方运行时崩溃
• CI/CD 无法按工具粒度发布：原来 cd tools/mailchimp && composer install --no-dev 就能独立部署，合并后一次 composer update 可能连累所有工具
• 真要省空间？用 composer install --prefer-dist --no-dev + 多层缓存，别碰结构隔离

最常被忽略的一点：IDE 或调试器是否真的加载了项目 vendor/autoload.php。很多 PHPStorm 用户以为配置了项目 SDK 就万事大吉，其实它默认可能仍在用全局 autoloader，导致断点进不去、类型提示错乱——这和命令行冲突是同一根源，只是发生在另一个执行上下文里。