composer.json 里改 vendor-dir 最直接
想换 vendor 目录位置，不是靠命令行参数或全局配置，而是改项目根目录下的 composer.json。它支持一个叫 config 的字段，里面可以指定 vendor-dir 路径。
常见错误是以为运行 composer install 时加个 --vendor-dir=xxx 就能生效——其实这个参数早被移除了，现在完全不认。
- 路径必须是相对当前
composer.json的相对路径，比如"vendor-dir": "lib/vendor"或绝对路径"vendor-dir": "/var/www/myproject/vendor" - 改完后要删掉旧
vendor目录再跑composer install，否则 Composer 可能复用旧结构，导致 autoload 错乱 - 如果用了 symlink（比如 Laravel 的
public/vendor），注意新路径下符号链接是否仍有效
环境变量 COMPOSER_VENDOR_DIR 优先级更高
当项目需要在不同环境（CI/CD、Docker、多租户部署）动态切换 vendor 路径时，硬编码进 composer.json 就不灵活了。这时可以用环境变量覆盖。
它的优先级高于 composer.json 里的 vendor-dir，只要 shell 里设了，Composer 启动时就自动读取。
- Linux/macOS：运行前执行
export COMPOSER_VENDOR_DIR="/tmp/myvendor" - Windows CMD：
set COMPOSER_VENDOR_DIR=C:\myproject\vendor - Docker 中建议写进
Dockerfile的ENV或docker run -e参数里，避免污染镜像 - 注意：PHP-FPM 或 Apache mod_php 环境中，该变量需在 Web 服务器启动前注入，不能只在 shell 里 export
自定义路径后 autoload 和 bin 目录会跟着变
vendor 目录一动，Composer 自动生成的自动加载文件（vendor/autoload.php）和可执行脚本（vendor/bin）位置也跟着变。很多工具链默认只认 vendor/autoload.php，路径一改就报 Class not found 或 Command not found。
这不是 bug，是设计使然——Composer 把所有依赖管理逻辑都锚定在 vendor 根目录上。
-
require 'vendor/autoload.php'必须同步改成新路径，比如require 'lib/vendor/autoload.php' - 使用
phpunit、phpcs这类 bin 工具时，确保调用的是lib/vendor/bin/phpunit而不是旧路径 - Laravel 的
artisan不受影响，但它内部 require 的autoload.php仍要指向新 vendor - IDE（如 PHPStorm）可能缓存旧 vendor 路径，需要手动刷新 External Libraries 或重新索引
别忽略 composer.lock 和团队协作影响
composer.lock 文件本身不记录 vendor 路径，但它锁定了包版本和哈希值。一旦你改了 vendor-dir，又没提交变更后的 composer.json，队友拉代码后运行 composer install 会照旧生成到默认 vendor，结果两边 vendor 目录不一致，git status 还可能误报修改。
更隐蔽的问题是：某些私有包的 autoload-dev 或 scripts 里写了硬编码的 vendor 路径，一换目录就执行失败。
- 改路径后务必把更新后的
composer.json提交进 Git - CI 脚本里如果显式清除了
vendor，要同步更新为清除新路径 - 检查所有
composer.json的scripts字段，避免出现"post-install-cmd": "cp vendor/foo/bar.php ./dist/"这类硬编码
路径看着只是字符串替换，但 vendor 是 Composer 整个依赖模型的物理锚点，动它就得通盘考虑加载、执行、协作、缓存这四层连带反应。
