不能直接挪动vendor目录，因Composer硬编码路径、生成静态 autoload 映射并记录锁文件哈希；手动移动会导致Class not found或install失败。推荐用COMPOSER_VENDOR_DIR环境变量重装到新位置，或抽离为私有包复用。
Composer 的 vendor 目录能直接挪到新位置吗
不能直接移动 vendor 目录并期望 Composer 继续正常工作。Composer 在安装依赖时会硬编码部分路径（比如 autoload_static.php 里的文件路径、composer/autoload_classmap.php 中的映射），还会在 composer.lock 和 vendor/composer/installed.json 中记录包的安装路径和哈希。手动移动后，composer install 或 composer update 很可能报错或重建整个 vendor。
用 COMPOSER_VENDOR_DIR 环境变量切换 vendor 位置
这是最干净、官方支持的方式，适合想把共享依赖集中到某处（比如项目外的 /opt/my-shared-vendor）再复用。它让 Composer 完全在指定路径下管理依赖，所有自动加载、锁文件路径都随之适配。
实操建议：
- 在运行 Composer 命令前设置环境变量：
COMPOSER_VENDOR_DIR="/opt/my-shared-vendor" composer install
- 也可以写进 shell 配置（如
~/.bashrc）永久生效：export COMPOSER_VENDOR_DIR="/opt/my-shared-vendor"
- 注意：该变量只影响当前命令或 shell 会话；不同项目若共用同一
COMPOSER_VENDOR_DIR，必须确保它们的composer.json兼容（PHP 版本、扩展要求、依赖版本无冲突），否则composer install会失败 - 首次使用时，Composer 会清空目标目录并重新下载安装 —— 不是“迁移”，而是“重装到新位置”
为什么不用 symlink 或修改 composer.json 的 config → vendor-dir
"config": { "vendor-dir": "..." } 确实能改 vendor 路径，但它写死在项目级配置里，不便于跨项目共享；而软链接（symlink）看似省事，但会导致两个问题：
-
composer dump-autoload --optimize生成的优化类映射中，路径仍指向原始 vendor 位置，运行时报Class not found - 某些插件（如
hirak/prestissimo）或 CI 工具对 symlink 支持不稳定，容易缓存旧路径 - 多个项目 symlink 到同一个物理
vendor目录时，composer update可能因并发写入损坏installed.json或锁文件
共享 vendor 的实际限制和替代思路
真正安全的“共享依赖”在 Composer 生态中其实受限很大 —— 它不是 npm 的 node_modules 那种扁平化结构，而是按项目隔离的层级式 autoload + 自动版本解析。强行共享容易踩坑：
- 不同项目 require 同一包的不同版本（如
monolog/monolog:^2.0vs^3.0），无法共存于一个vendor -
composer global是唯一官方共享机制，但只适用于 CLI 工具类包（如phpunit,laravel/installer），不适用项目运行时依赖 - 若只为加速安装，优先考虑
composer install --prefer-dist --no-scripts+ 启用cache-dir（默认已启用），比共享vendor更可靠
真要跨项目复用代码，更合理的是把公共逻辑抽成私有 Packagist（或 Git repo），然后各项目 require 它 —— vendor 是项目的，不是共享资源池。
