直接在composer.json顶层添加"config": {"vendor-dir": "lib/vendor"}可指定新vendor目录，需删除旧vendor后运行composer install/update，路径须避免嵌套在原vendor内且注意跨平台兼容性。
composer.json 里用 config.vendor-dir 指定新路径
直接改 vendor 目录，不是靠命令行参数或全局配置，而是改项目根目录下的 composer.json。只要加一行 config 配置就能生效，Composer 会优先读它。
- 在
composer.json的顶层（和require同级）加："config": { "vendor-dir": "lib/vendor" } - 路径支持相对路径（推荐），也支持绝对路径（如
/var/www/myapp/vendor），但绝对路径会让项目失去可移植性 - 改完后必须删掉旧
vendor目录，再运行composer install或composer update，否则 Composer 不会自动迁移文件 - 如果项目已提交了
vendor到 Git，记得把旧路径从版本控制里删掉，并更新.gitignore（比如改成lib/vendor/）
全局配置 COMPOSER_VENDOR_DIR 环境变量不推荐
环境变量方式确实能覆盖 vendor 路径，但它属于“强制干预”，容易在 CI、多项目共存或团队协作时出问题。
- 设置方式：
export COMPOSER_VENDOR_DIR="/path/to/vendor（Linux/macOS）或set COMPOSER_VENDOR_DIR=C:path o endor（Windows） - 它会跳过
composer.json里的config.vendor-dir，连带影响所有子命令（composer dump-autoload也会找错地方） - CI 脚本里误设该变量，会导致本地开发和构建环境行为不一致，debug 成本高
- 除非是临时调试或容器内固定路径场景，否则别用
修改后 autoload 和 bin 路径会自动适配
不用担心 PSR-4 自动加载或脚本命令失效——Composer 会根据新的 vendor-dir 重写 vendor/autoload.php 和 vendor/bin/ 下的可执行文件。
-
vendor/autoload.php仍可照常引入，路径逻辑由 Composer 内部处理，无需手动改 require - 如果项目里硬编码了
vendor/autoload.php（比如某些部署脚本），要同步改成新路径，例如lib/vendor/autoload.php -
bin目录下的命令（如phpunit、laravel）依然能用，但前提是它们没被 symlink 到系统 PATH；若用了composer global，那和当前项目的vendor-dir无关
注意 vendor-dir 不能放在 vendor 内部或循环引用
这个坑很隐蔽：一旦配置值指向了 vendor 子目录（比如 "vendor-dir": "vendor/mylibs"），Composer 会卡住或报错，甚至删掉整个 vendor。
- 错误现象：
Could not delete /path/to/vendor/composer或RecursiveDirectoryIterator报错 - 根本原因：Composer 在清理旧 vendor 时，会递归删除整个目录，而新路径若在旧 vendor 内，就触发自相矛盾的删除逻辑
- 安全做法：新路径必须和原
vendor平级（如lib/vendor）或上级（如../shared/vendor），且不能是任何已存在 vendor 的子路径 - Windows 下还要留意路径分隔符，统一用正斜杠
/或双反斜杠\，避免因单反斜杠被解析为转义字符
vendor 去找类定义。 
