Composer怎么自定义安装路径_Composer自定义包安装路径教程【深入】-composer-PHP中文网

唯一靠谱的全局改路径方式是 config.vendor-dir，需在 composer.json 中配置相对路径如 "third-party"，删旧 vendor 后重装，并手动更新所有硬编码路径、ide 设置及 ci 脚本。

composer怎么自定义安装路径_composer自定义包安装路径教程【深入】

config.vendor-dir 是唯一靠谱的全局改路径方式

想让所有 Composer 包不装进 vendor，而是进 third-party 或 lib/vendor？只有 config.vendor-dir 这个配置项是官方完全支持、全命令生效（install、update、require 都认）的正路。

在项目根目录的 composer.json 里加这段：
```
{ "config": { "vendor-dir": "third-party" } }
```
路径必须是相对路径，不能以 / 开头（third-party ✅，/third-party ❌）
改完后必须删掉旧 vendor 目录，再跑 composer install —— 否则旧包还在原地，autoload 和 bin 链接不会重建
composer dump-autoload 不够用，它只刷新类映射，不挪目录、不重写 autoload.php 入口

改了 vendor-dir，为什么 require 'vendor/autoload.php' 突然报错？

因为 PHP 代码里硬编码了路径。Composer 不会自动帮你改你自己的 require 语句，也不会改部署脚本、IDE 配置或 CI 流水线里的引用。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

所有 require 'vendor/autoload.php'; 得手动改成 require 'third-party/autoload.php';
vendor/bin/phpunit 变成 third-party/bin/phpunit，PATH 或 shell 脚本里调用的地方也要同步改
PHPStorm 默认只索引 vendor 目录，得手动去 Settings → PHP → Include Paths 加上新路径
某些插件或框架脚本（比如 Laravel 的 artisan 初始化逻辑）可能内部拼了 vendor 字符串，这类要查源码或 patch

installer-paths 只对特定 type 的包生效，别指望它动普通库

installer-paths 不是“换个地方装所有依赖”，它是给 WordPress 插件、Drupal 模块、TYPO3 扩展这类有明确 type 的包走定制路径用的。普通 PHP 库（type: library）压根不走这条路。

先确认目标包在 Packagist 上声明的 type，比如 wpackagist-plugin/akismet 的 type 是 wordpress-plugin
确保已执行 composer require composer/installers，否则 extra.installer-paths 完全无效

配置示例：

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

路径值是相对于项目根目录的，不能以 / 开头；多条规则按顺序匹配，只取第一个命中项

环境变量 COMPOSER_VENDOR_DIR 有优先级陷阱

它确实能临时覆盖 config.vendor-dir，但只在项目没声明 config.vendor-dir 时才生效——一旦 composer.json 里写了，环境变量就被无视了。

Linux/macOS：COMPOSER_VENDOR_DIR=lib/vendor composer install
Windows CMD：set COMPOSER_VENDOR_DIR=lib\vendor && composer install
CI 脚本中滥用这个变量却不检查项目配置，容易导致本地正常、流水线报 Class not found
某些 Docker 镜像或托管平台（如 GitHub Actions 的默认 runner）不加载用户级环境变量，设了也白设

改路径本身很简单，真正难的是让 autoload、bin 调用、IDE、CI、部署脚本、甚至第三方插件全部跟上这个变化——漏掉任意一环，就卡在 Class not found 或 command not found 上。