composer install 在共享机器上会互相污染，因多人共用时全局配置、autoload 路径未隔离及 lock 文件不一致导致 vendor 类交叉加载；必须执行三步：锁定 composer_home 到项目内、显式声明 composer.json、仅调用 ./vendor/bin/ 下脚本。
为什么 composer install 在共享机器上会互相污染？
因为默认情况下，Composer 会把依赖装进项目目录下的 vendor/，看似隔离——但问题出在 composer.lock 和 PHP 的 include_path 或自动加载机制上。多人共用一台开发机时，如果有人手动改过全局 composer.json、或误用 composer global require，再配合不严格的 autoload 配置（比如用了 psr-0 且未限定命名空间前缀），就可能让 A 项目的 vendor/autoload.php 加载到 B 项目的类。
确保项目级隔离的三个硬性操作
不是“推荐”，是必须做齐这三步，否则隔离就是假象：
- 每次进入项目目录后，先运行
export COMPOSER_HOME="$(pwd)/.composer"—— 这让 Composer 把缓存、配置、全局 bin 都锁死在当前项目下，避免复用系统级~/.composer - 在项目根目录放一个显式的
composer.json，哪怕只是空壳：{ "name": "my/project", "type": "project" }；没有它，
composer install可能降级到查找父目录的配置 - 所有脚本调用必须走项目内
vendor/bin/，例如用./vendor/bin/phpunit而非phpunit；检查$PATH是否意外包含了其他项目的vendor/bin
composer install vs composer update 在共享环境中的行为差异
二者对锁文件和 vendor 的处理逻辑不同，直接影响隔离稳定性：
-
composer install严格按composer.lock安装，不读远程包信息，适合部署和多人同步——但前提是lock文件已提交且未被本地修改 -
composer update会忽略lock，重新解析依赖树并生成新lock；在共享机上，只要某人执行过一次，就可能把整个团队的依赖版本带偏 - CI/CD 或共享机上应禁用
update，只允许install；可用composer install --no-dev --prefer-dist进一步减少干扰
PHP 自动加载器怎么悄悄破坏隔离？
即使 vendor/ 是分开的，如果项目用了 classmap 或自定义 autoload.files，且路径写成绝对路径（如 /home/user/project/src/helpers.php），那换个人 checkout 到 /home/other/project 就直接报 failed to open stream；更隐蔽的是 psr-4 映射没加尾部反斜杠，导致 "App": "src" 和 "App": "src/" 在某些 PHP 版本下行为不一致。
解决办法很简单：全部用相对路径 + 显式尾部斜杠，且在 composer.json 中统一写成
"autoload": { "psr-4": { "App": "src/" } }；然后每次改完立刻跑 composer dump-autoload --optimize，别信 ide 自动生成的 autoload。
真正麻烦的从来不是装不上包，而是某个类在你机器上能 load，在别人机器上 silent fail —— 因为自动加载器跳过了错误提示，只返回 NULL 或触发 __autoload 回退逻辑。