唯一真正可靠、全命令一致生效的方式是设置环境变量composer_vendor_dir；config.vendor-dir在composer 2.0+已彻底废弃，写入composer.json会触发警告且完全不生效，所有安装命令仍使用默认vendor/目录。
Composer 自定义 vendor 目录，唯一真正可靠、全命令一致生效的方式是设置环境变量 COMPOSER_VENDOR_DIR；config.vendor-dir 在 Composer 2.0+ 已被官方废弃，继续使用会触发明确警告且完全不生效。
为什么 config.vendor-dir 不再起作用
自 Composer 2.0 起，config.vendor-dir 字段已被移除逻辑支持。你在 composer.json 里写：
"config": {
"vendor-dir": "lib/vendor"
}
只会收到警告：The "config.vendor-dir" option is deprecated, use the "COMPOSER_VENDOR_DIR" environment variable instead.，然后 Composer 照旧把包装进默认 vendor/。
- 它不会影响
composer install、composer update或composer require的实际安装路径 - 删掉旧
vendor/后重装也无效——因为配置根本没被读取 - 某些旧文档或插件仍提这个字段，但那是过时信息，2026 年所有稳定版（如 2.9.6）均不再识别
怎么用 COMPOSER_VENDOR_DIR 正确设置
这是当前唯一受官方支持、覆盖全部命令的路径控制方式，优先级最高，且无需改项目配置文件。
- Linux/macOS（临时）：
COMPOSER_VENDOR_DIR=third-party composer install - Windows CMD：
set COMPOSER_VENDOR_DIR=third-party && composer install - PowerShell：
$env:COMPOSER_VENDOR_DIR="third-party"; composer install - 路径可为相对（
third-party）或绝对（/var/www/myapp/deps），但不能以/开头的“伪绝对路径”（如/third-party），否则 Windows 下易解析失败 - 该变量只对当前命令生效，不污染全局，也不写入任何配置，适合 CI/CD 流水线统一控制
改完后 autoload.php 引入路径必须手动同步
COMPOSER_VENDOR_DIR 只改变依赖安装位置，vendor/autoload.php 这个路径是硬编码在你代码里的——Composer 不会自动帮你替换 PHP 文件中的字符串。
- 如果原代码写的是
require 'vendor/autoload.php';，现在autoload.php实际在third-party/autoload.php，就会报错failed to open stream: No such file or directory - 所有显式引用都要改成新路径，例如：
require 'third-party/autoload.php'; - 部署脚本、测试启动器、Web 入口文件（如
public/index.php）都得检查一遍 - IDE（如 PHPStorm）通常能自动识别新路径下的类，但需确保
.idea/misc.xml或索引未缓存旧 vendor 结构
extra.installer-paths 是另一回事，别混用
这个字段不是用来改 vendor 根目录的，它只对声明了特定 type 的包生效（比如 wordpress-plugin、drupal-module），且必须先 composer require composer/installers。
- 普通 PHP 库（如
monolog/monolog、guzzlehttp/guzzle）完全不受extra.installer-paths影响 - 它和
COMPOSER_VENDOR_DIR是正交机制：一个管整个依赖根目录，一个管生态型子包的落地位置 - 误以为设了
extra.installer-paths就能绕过COMPOSER_VENDOR_DIR，结果发现核心依赖还在vendor/里，是常见理解偏差
最易被忽略的一点：CI/CD 中若只在 Dockerfile 或构建脚本里漏设 COMPOSER_VENDOR_DIR，而本地开发又靠环境变量临时覆盖，会导致构建产物中 autoload 路径错位、类加载失败——这种不一致很难复现，必须把环境变量作为构建契约的一部分固化下来。
