COMPOSER_VENDOR_DIR环境变量可优先覆盖composer.json中vendor-dir配置，控制vendor目录位置，但需同步更新autoload.php引入路径并确保各环境一致。
如何用 COMPOSER_VENDOR_DIR 指定 vendor 目录位置
Composer 默认把依赖装到项目根目录下的 vendor 文件夹，但如果你的部署结构不允许（比如 Web 根目录不能有 vendor），就得改路径。最直接的方式是通过环境变量控制：COMPOSER_VENDOR_DIR。
它优先级高于 composer.json 里的配置，且在 composer install 和 composer update 时都生效。
- Linux/macOS：运行前临时设置
COMPOSER_VENDOR_DIR=/path/to/your/vendor - Windows CMD：用
set COMPOSER_VENDOR_DIR=C:\my\vendor - Windows PowerShell：用
$env:COMPOSER_VENDOR_DIR="C:\my\vendor"
注意：这个变量只影响依赖安装位置，不自动修改自动加载逻辑——你得手动确保 autoload.php 被正确引入。
为什么 vendor-dir 配置项有时不生效
composer.json 里写 "config": { "vendor-dir": "lib/vendor" } 看似合理，但它只在没有设置 COMPOSER_VENDOR_DIR 环境变量时才起作用。一旦环境变量存在，它就完全被忽略。
另一个常见陷阱：该配置项不会改变已存在的 vendor 目录行为。比如你先运行过 composer install（默认生成了 vendor），再加 vendor-dir 配置，下次 update 仍会复用原目录，除非你先删掉旧 vendor 并清空 composer.lock 中的路径缓存（实际是重装）。
- 推荐做法：首次初始化就设好环境变量，避免中途切换
- CI/CD 中务必统一设置该变量，否则本地和构建机路径不一致会导致
Class not found - 该配置对
composer dump-autoload无影响——它只读取当前vendor下的autoload.php
autoload.php 路径变动后怎么让代码正常加载
改了 vendor 位置，require 'vendor/autoload.php' 就会失败。你必须同步更新所有引入点。
常见做法是用相对路径或常量兜底：
require __DIR__ . '/lib/vendor/autoload.php';
更健壮的方式是检测路径是否存在，避免硬编码：
$vendorAutoload = [
__DIR__ . '/vendor/autoload.php',
__DIR__ . '/lib/vendor/autoload.php',
__DIR__ . '/shared/vendor/autoload.php',
];
foreach ($vendorAutoload as $path) {
if (file_exists($path)) {
require $path;
break;
}
}
如果用的是框架（如 Laravel、Symfony），还要检查其引导文件（如 bootstrap/autoload.php 或 public/index.php）是否仍指向旧路径。
使用符号链接能否替代环境变量
有人倾向用 ln -s /real/vendor ./vendor，短期可行，但有隐患：
- 某些共享主机禁用符号链接（
open_basedir限制下会报错） - Git 不跟踪软链目标，协作时容易漏掉真实
vendor位置信息 - Docker 多阶段构建中，构建阶段的
vendor若靠软链挂载，运行阶段可能丢失 -
composer global不受项目级软链影响，仍走全局~/.composer/vendor
环境变量方式更透明、可审计，也更容易集成进部署脚本或容器 ENTRYPOINT。
真正麻烦的不是改路径，而是让所有运行环境（开发、测试、CI、生产）一致地识别新路径，并确保 autoload.php 加载链不中断——这点比安装本身更值得花时间验证。
