Composer install 在共享机器上会互相污染，因多人共用时全局配置、autoload 路径未隔离及 lock 文件不一致导致 vendor 类交叉加载；必须执行三步：锁定 COMPOSER_HOME 到项目内、显式声明 composer.json、仅调用 ./vendor/bin/ 下脚本。
为什么
在共享机器上会互相污染？
因为默认情况下，Composer 会把依赖装进项目目录下的
，看似隔离——但问题出在
和 PHP 的
或自动加载机制上。多人共用一台开发机时，如果有人手动改过全局
、或误用
，再配合不严格的
配置（比如用了
且未限定命名空间前缀），就可能让 A 项目的
加载到 B 项目的类。
确保项目级隔离的三个硬性操作
不是“推荐”，是必须做齐这三步，否则隔离就是假象：
每次进入项目目录后，先运行
—— 这让 Composer 把缓存、配置、全局 bin 都锁死在当前项目下，避免复用系统级
在项目根目录放一个显式的
，哪怕只是空壳：
；没有它，
可能降级到查找父目录的配置
所有脚本调用必须走项目内
，例如用
而非
；检查
是否意外包含了其他项目的
vs
在共享环境中的行为差异
二者对锁文件和 vendor 的处理逻辑不同，直接影响隔离稳定性：
严格按
安装，不读远程包信息，适合部署和多人同步——但前提是
文件已提交且未被本地修改
会忽略
，重新解析依赖树并生成新
；在共享机上，只要某人执行过一次，就可能把整个团队的依赖版本带偏
CI/CD 或共享机上应禁用
，只允许
；可用
进一步减少干扰
PHP 自动加载器怎么悄悄破坏隔离？
即使
是分开的，如果项目用了
或自定义
，且路径写成绝对路径（如
），那换个人 checkout 到
就直接报
；更隐蔽的是
映射没加尾部反斜杠，导致
和
在某些 PHP 版本下行为不一致。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
解决办法很简单：全部用相对路径 + 显式尾部斜杠，且在
中统一写成
；然后每次改完立刻跑
，别信 IDE 自动生成的 autoload。
真正麻烦的从来不是装不上包，而是某个类在你机器上能 load，在别人机器上 silent fail —— 因为自动加载器跳过了错误提示，只返回
或触发
回退逻辑。
composer installvendor/composer.lockinclude_pathcomposer.jsoncomposer global requireautoloadpsr-0vendor/autoload.phpexport COMPOSER_HOME="$(pwd)/.composer"~/.composercomposer.json{ "name": "my/project", "type": "project" }composer installvendor/bin/./vendor/bin/phpunitphpunit$PATHvendor/bincomposer installcomposer updatecomposer installcomposer.locklockcomposer updatelocklockupdateinstallcomposer install --no-dev --prefer-distvendor/classmapautoload.files/home/user/project/src/helpers.php/home/other/projectfailed to open streampsr-4"App": "src""App": "src/"composer.json"autoload": { "psr-4": { "App\": "src/" } }composer dump-autoload --optimizenull__autoload