唯一真正生效的全局路径控制方式是config.vendor-dir，必须写在项目根目录composer.json中、删掉旧vendor后执行composer install；其他方法如extra.installer-paths仅对特定type包生效且需插件支持，-d参数和composer_vendor_dir环境变量均不可靠。

唯一真正生效的全局路径控制方式是 config.vendor-dir，必须写在项目根目录 composer.json 中、删掉旧 vendor 后执行 composer install；其他所谓“换路径”方法要么不生效，要么只对特定包起作用且依赖额外插件。

改整个项目的 vendor 目录位置，只认 config.vendor-dir

Composer 不接受命令行参数或环境变量来可靠地重定向所有包的安装位置。唯一被所有命令（install、update、require）一致识别的配置项是 config.vendor-dir。

• 必须写在项目根目录的 composer.json 里，例如：

  {"config": {"vendor-dir": "third-party"}}

• 路径必须是相对路径（如 "lib"、"vendor-custom"），不能以 / 开头，否则在 Windows 或某些 CI 环境下会出错
• 该配置仅在 vendor 目录不存在时生效；如果已运行过 composer install，必须手动删除整个 vendor 目录再重装
• composer dump-autoload 完全无效——它不重建目录结构，也不更新 autoload.php 入口路径
• 改完后，所有硬编码引用都要同步更新：require 'vendor/autoload.php' → require 'third-party/autoload.php'

extra.installer-paths 只对声明了 type 的包生效

想把某个 WordPress 插件装进 wp-content/plugins/，或把 Drupal 模块放进 web/modules/contrib/，才需要这个机制。它不是“通用路径替换”，而是插件驱动的定制安装逻辑。

First Principles Decomposer

把任何问题拆解为根本真理，再从原子层面重建解决方案。

下载

• 前提是你已运行 composer require composer/installers（或对应专用 installer，如 wpackagist/installer）
• 目标包自身 composer.json 中必须声明匹配的 type，比如 "type": "wordpress-plugin"
• 配置写在根项目 composer.json 的 extra 字段下，例如：

  "extra": {"installer-paths": {"wp-content/plugins/{$name}/": ["type:wordpress-plugin"]}}

• 路径值是相对于项目根目录的，不能以 / 开头；{$name} 会被替换成包名（不含 vendor 部分）
• 普通 PHP 库（type: library）完全不受影响，哪怕你写了规则也进不了指定目录

-d 参数和 COMPOSER_VENDOR_DIR 都不可靠

很多人以为 composer -d /path install 能切换安装位置，或者设个环境变量就能生效——实际它们要么被忽略，要么只在极少数场景下偶然起效，根本不适合生产使用。

• -d 只改变 Composer 查找 composer.json 和 composer.lock 的路径，对 vendor 写入位置零影响
• COMPOSER_VENDOR_DIR 在部分旧版 Composer 中曾短暂支持，但自 2.0+ 起已被移除或降级为未文档化行为，CI 环境中极易失效
• 全局 COMPOSER_HOME/config.json 中设 vendor-dir 理论可行，但会导致所有项目共用同一 vendor，引发版本冲突，且无法提交到 Git 协作
• 试图用软链接伪装 vendor 名称（如 ln -s third-party vendor）虽能绕过部分工具限制，但会掩盖真实路径问题，调试时容易误判

改了 vendor-dir 后 bin 文件和 IDE 索引也得手动跟上

Composer 生成的二进制文件（如 phpunit、laravel-env）默认链向 vendor/bin/。路径一变，这些链接就断了，而且 IDE 不会自动发现新目录。

• 必须在 config 中同步指定 bin-dir，例如：

  "config": {"vendor-dir": "third-party", "bin-dir": "third-party/bin"}

• CI 脚本、部署命令、shell 的 PATH 中所有对 vendor/bin/xxx 的调用都得手动更新
• PHPStorm 默认只索引 vendor，需手动进入 Settings → PHP → Include Paths 添加新路径
• 某些框架脚本（如 Laravel 的 artisan 初始化逻辑）内部拼接了 vendor 字符串，这类要查源码确认是否兼容

最常被忽略的是：改路径不是改一个配置就完事，它牵扯到 autoload 入口、bin 链接、IDE 设置、CI 脚本、甚至某些框架的硬编码路径逻辑。一旦漏掉其中一环，就会出现“明明装好了却 Class not found”的问题。