唯一真正生效的是config.vendor-dir字段，必须写在项目根目录composer.json中，路径为相对路径（如"third-party"），且需先删除旧vendor再执行composer install。
vendor-dir 可以改成任意合法的相对目录名，比如 libs、deps、third-party，但不能叫 vendor 以外的名字再放在默认位置——它本质是改路径，不是单纯“改名”。
vendor-dir 的合法取值范围
这个字段只接受字符串形式的相对路径（不以 / 开头），且不能含 .. 或变量占位符：
-
"vendor-dir": "libs"→ 生成./libs/，合法 -
"vendor-dir": "src/vendor"→ 生成./src/vendor/，合法（注意：Composer 不会自动创建src/，得手动建好） -
"vendor-dir": "libs/"→ 末尾斜杠会触发Invalid value for vendor-dir错误 -
"vendor-dir": "./libs"→./被忽略，实际等价于"libs"，不推荐写法 -
"vendor-dir": "${HOME}/my-vendor"→ 直接报错Invalid config key 'vendor-dir'
为什么不能直接把 vendor 目录重命名为 deps？
Composer 源码里硬编码了对 vendor/autoload.php 的引用逻辑。你手动 mv vendor deps 后：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer dump-autoload仍试图读vendor/composer/autoload_classmap.php，报错 - 已生成的
vendor/autoload.php文件里，__DIR__ . '/composer/'这类路径不会变，加载器找不到映射 - 所有 bin 脚本（如
vendor/bin/phpunit）的 shebang 和 require 行都指向vendor/，运行即失败
改完 vendor-dir 后必须同步处理的三件事
否则项目大概率在第一次 require 时就 Fatal error：
- 入口文件（如
public/index.php）里的require 'vendor/autoload.php'得改成require __DIR__ . '/../libs/autoload.php'（假设你设的是"libs"） - CI/CD 脚本、Dockerfile 中所有显式引用
vendor/的路径，比如COPY vendor/ /app/vendor/，要同步换成COPY libs/ /app/libs/ -
.gitignore原来写的/vendor得删掉，加上新路径，比如/libs；否则新目录可能被意外提交
COMPOSER_VENDOR_DIR 环境变量到底靠不靠谱？
它只在 composer install 和 composer update 时生效，且优先级高于 config.vendor-dir；但其他命令（dump-autoload、run-script、diagnose）完全不认它：
- 设
COMPOSER_VENDOR_DIR=third-party后跑composer install→ 包真装进third-party/ - 但紧接着跑
composer dump-autoload→ 它仍去vendor/下找 autoload_files 配置，或报错找不到vendor/autoload.php - 更隐蔽的问题：
third-party/autoload.php文件里生成的路径仍是__DIR__ . '/vendor/composer/'，因为 autoloader 生成逻辑和环境变量无关
真正麻烦的不是怎么设，而是它不报错、不警告、不迁移——你改完以为好了，直到某次 CI 构建失败才意识到，整个生态链里到处埋着对 vendor/ 的隐式依赖。
