Composer不支持将vendor直接装到项目外绝对路径（如/opt/my-vendor）并正常工作，因autoload.php硬编码相对路径、类加载失败、插件检测异常；可行方案仅三类：符号链接、COMPOSER_VENDOR_DIR环境变量、共享缓存/路径仓库。
Composer 本身不支持直接把 vendor 目录“装到项目外任意路径”并正常工作——这不是设计目标，强行挪动只会让 autoload.php 生成的路径错乱、类加载失败、插件脚本不执行。真正可行的方案只有三类：符号链接、环境变量控制、或改用缓存/路径仓库等替代机制。
为什么不能直接把 vendor 放到 /opt/my-vendor 这种系统级路径？
因为 vendor/autoload.php 在生成时，会硬编码大量相对路径（比如映射表里写的是 ../src/MyClass.php），一旦 vendor 不在项目根目录下，这些路径就全失效；composer dump-autoload 也会报错或静默生成错误映射；第三方包里的 files 或 classmap 加载逻辑同样依赖当前项目结构。
-
vendor-dir配置只接受项目内相对路径（如../shared/vendor），不能是绝对路径 - 即使通过
COMPOSER_VENDOR_DIR=/opt/vendor composer install强行指定，生成的 autoload 文件仍可能含错误路径，运行时抛出Class not found - 某些 Composer 插件（如 PHPStan、PHPUnit 集成）会检查
vendor是否在预期位置，路径异常会导致跳过加载
用符号链接（symlink）安全复用 vendor 目录
这是最稳定、兼容性最好的方式：保持项目内有 vendor 这个名字，但让它指向外部真实位置。所有工具链（IDE、CI、PHP CLI）都无感，自动加载完全不受影响。
- Linux/macOS：先创建目标目录
/shared/myproject-vendor，再运行ln -s /shared/myproject-vendor ./vendor - Windows（管理员权限）：
mklink /D vendor C:\shared\myproject-vendor - 执行
composer install前确保./vendor是空目录或不存在，否则链接会被覆盖 - 多个项目共用同一
vendor目录时，必须保证所有项目依赖的包版本完全一致，否则会出现类定义冲突
用 COMPOSER_VENDOR_DIR 环境变量的注意事项
它能改变 composer install 的输出位置，但不是“一设就灵”。关键限制在于 autoload 机制对路径的敏感性。
- 设置后必须重新运行
composer dump-autoload，否则旧的autoload.php仍引用原路径 -
vendor/autoload.php内部会用__DIR__定位自身，再拼接其他文件路径；若vendor在上级目录，__DIR__可能跨出项目根，导致files列表 require 失败 - Docker 构建中若未在
ENV或run步骤显式设置该变量，容器内仍会回退到默认位置 - CI 脚本里别只写
export COMPOSER_VENDOR_DIR=...，要确认 shell 执行上下文是否继承该变量（比如 GitHub Actions 的run默认不共享 env）
真正省事的替代方案：共享缓存 + path repository
多数人想挪 vendor 其实是为了节省磁盘或统一管理——这两点完全不用动 vendor 目录就能做到。
- 共享下载缓存：设置
COMPOSER_HOME或cache-dir，让不同项目复用已解压的 ZIP 包，安装速度提升 5–10 倍，且不影响 autoload - 开发内部包：用
"type": "path"仓库，把本地工具包目录（如../my-utils）注册为源，composer require my-vendor/utils:dev-main会自动创建 symlink，改源码立刻生效 - 上线前切回 packagist 或私有 repo，业务代码一行不用改
最常被忽略的一点：autoload 机制本身不关心 vendor 物理在哪，只认 vendor/autoload.php 这个入口文件是否被正确引入、以及它生成的映射是否有效。路径问题永远要从“这个文件能不能被 require、它 require 的其他文件路径对不对”去验证，而不是盲目相信配置项写了就生效。
