直接修改 vendor-dir 是唯一可靠方式，需在项目 composer.json 的 config 字段中配置相对路径（如 "third-party"），删掉原 vendor 后执行 install/update，并同步更新所有 require 语句及 IDE、CI 等相关路径。
直接改 vendor-dir 是唯一可靠方式，其他方法要么不生效，要么后续一堆路径报错。
在项目 composer.json 中配置 config.vendor-dir
这是最常用、最可控的做法。Composer 只认这个位置的 vendor-dir 配置，且仅对当前项目生效。
- 编辑项目根目录下的
composer.json，在config字段里写死路径，比如：{"config": {"vendor-dir": "third-party"}} - 路径可以是相对路径（推荐），如
"third-party"或"lib/vendor"；避免用以/开头的“伪绝对路径”，Windows 下容易解析失败 - 改完必须删掉现有
vendor目录，再执行composer install或composer update——dump-autoload不行，它不重建autoload.php和符号链接 - 所有代码中
require 'vendor/autoload.php'都得手动改成新路径，例如require 'third-party/autoload.php'
环境变量 COMPOSER_VENDOR_DIR 临时覆盖
适合 CI/CD 脚本或一次性调试，但不能替代配置文件，且极易漏设。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Linux/macOS：
COMPOSER_VENDOR_DIR=third-party composer install - Windows PowerShell：
$env:COMPOSER_VENDOR_DIR="third-party"; composer install - 该变量优先级高于
composer.json中的vendor-dir，但只影响本次命令，不持久 - PHP 运行时完全不感知这个变量，
require 'vendor/autoload.php'仍会报错，必须同步改代码里的路径 - Dockerfile 或部署脚本里漏设该变量，构建就会回退到默认
vendor/，导致类找不到
全局共享 vendor 路径（慎用）
适用于本地开发机上多个项目共用一套依赖，但线上部署、团队协作中基本不可行。
- 先设置
COMPOSER_HOME指向自定义目录，例如export COMPOSER_HOME="/opt/my-composer-home" - 然后在
/opt/my-composer-home/config.json里写：{"config": {"vendor-dir": "/opt/shared-vendor"}} - 注意：
COMPOSER_HOME本身不控制vendor位置，必须配合其下的config.json才生效 - 项目级
composer.json中的config字段对vendor-dir完全无效，这是 Composer 的硬限制 - IDE（如 PHPStorm）默认只索引
vendor，需手动添加新路径到 Settings → PHP → Include Paths
别碰 -d 参数，它根本不管 vendor 装哪
composer install -d /path 常被误用，但它只是让 Composer 去指定路径找 composer.json，和安装位置无关。
- 执行
composer install -d /tmp/myapp等价于cd /tmp/myapp && composer install，vendor 还是落在当前工作目录下（或已配置的vendor-dir） - CI 脚本里滥用这个参数，却没配
vendor-dir，结果本地跑通、流水线报Class not found - 如果真想把整个项目挪到别处构建，应该先
cd进去，再运行composer install，而不是靠-d
真正麻烦的不是改路径，而是所有硬编码的引用：autoload 引入、bin 文件调用、IDE 索引、CI 脚本里的 vendor/bin/phpunit……漏改一处，就卡住。最省事的方案，其实是保持默认 vendor，用符号链接指向外部目录。
