唯一真正生效的是config.vendor-dir字段，必须写在项目根目录composer.json中，路径为相对路径（如"third-party"），且需先删除旧vendor再执行composer install。
config.vendor-dir 是唯一真正生效的全局路径配置
改整个项目的依赖安装目录，只有 config.vendor-dir 这一个字段被 Composer 全命令（install、update、require）一致识别。它必须写在项目根目录的 composer.json 里，且只在 vendor 目录不存在时才起作用。
常见错误是先运行过 composer install，再补加这个配置——此时旧 vendor 还在，Composer 不会移动它，也不会把新包写到新路径。
- 路径必须是相对路径，比如
"third-party"✅，不能写成"/var/www/myapp/third-party"或"/third-party"❌ - 改完后必须手动删掉现有
vendor目录，再执行composer install（不是dump-autoload） -
composer.lock可以保留，但若想彻底重置，也建议一并删除
extra.installer-paths 只对特定 type 的包生效
extra.installer-paths 不是用来“自定义所有包的安装位置”的，它是 composer/installers 插件提供的能力，仅影响声明了明确 type（如 wordpress-plugin、drupal-module）的包。普通 PHP 库（如 monolog/monolog）完全不受影响。
如果你没装 composer/installers，这个配置直接被忽略；装了但目标包没声明对应 type，同样无效。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须先执行
composer require composer/installers - 路径值是相对于项目根目录的，不支持以
/开头，例如"wp-content/plugins/{$name}/"✅ - 规则按顺序匹配，只取第一个命中项，不会叠加或合并
- 已安装的包不会被自动迁移，删掉
vendor后重装才生效
-d 参数和 COMPOSER_VENDOR_DIR 环境变量都靠不住
composer -d /path install 只是告诉 Composer 去哪找 composer.json 和 composer.lock，它完全不改变 vendor 的写入位置。很多人误以为这能“换地方装”，结果本地跑通、CI 报 Class not found——因为 vendor 还在原项目下，而脚本却在别处找 autoload。
COMPOSER_VENDOR_DIR 环境变量只有在 composer.json 中未声明 config.vendor-dir 时才生效，优先级低于项目配置，且在 Docker、Git Bash 等环境下行为不稳定。
- CI 脚本里用
-d却没同步配config.vendor-dir，几乎必然出问题 - Windows 下设环境变量要用
set COMPOSER_VENDOR_DIR=lib\vendor，反斜杠需转义 - 全局配置不如项目级配置可靠，尤其当多个项目共存时
改路径后最常漏掉的三件事
真正难的不是改配置，而是让整个开发链路跟上新路径。稍有遗漏，就会出现类找不到、命令调不了、IDE 报红等问题。
-
require 'vendor/autoload.php'必须改成新路径，比如require 'third-party/autoload.php' - 所有硬编码的 bin 调用（如
vendor/bin/phpunit）要同步更新为third-party/bin/phpunit，并确认PATH或 CI 脚本已适配 - PHPStorm 等 IDE 默认只索引
vendor，需手动在 Settings → PHP → Include Paths 中添加新路径
这些不是可选步骤，而是改路径后必须同步完成的动作。否则你面对的不是“路径没改成功”，而是“看起来改了，但处处报错”。
