真正生效且可维护的方式只有一种：在composer.json中声明config.vendor-dir，并确保旧vendor已清空、autoload引入路径已同步更新；COMPOSER_VENDOR_DIR环境变量仅对少数命令有效，install/update仍写入默认vendor/，且autoload.php硬编码旧路径导致类加载失败。
不能靠改名、软链接或环境变量临时覆盖来“定制”vendor路径——真正生效且可维护的方式只有一种：在composer.json中声明config.vendor-dir，并确保旧vendor已清空、autoload引入路径已同步更新。
为什么COMPOSER_VENDOR_DIR环境变量不靠谱
它在 Composer 2.2+ 中仅对dump-autoload等少数命令起作用，install和update仍会写入默认vendor/目录。实测设为lib/ext后运行composer install，生成的autoload.php里依然硬编码__DIR__ . '/vendor/composer/autoload_real.php'，类加载必然失败。
CI/CD 脚本里误用这个变量是高频翻车点：本地跑通，部署后Class not found，因为自动加载器根本没读到新路径下的映射文件。
- 它不改变实际安装位置，只影响部分内部路径解析逻辑
- PHP opcode 缓存（如 OPCache）可能缓存旧
autoload.php，即使文件已重生成也不生效 - Docker 或 Git Bash 环境下行为不稳定，不建议依赖
config.vendor-dir必须满足的三个硬性条件
这个配置不是“设了就生效”的开关，它只在vendor目录不存在时触发安装逻辑。一旦已有vendor/，再改配置也不会迁移或覆盖。
- 路径必须是相对路径，例如
"third-party"✅，不能是"/third-party"或"../libs"❌ - 父目录（如
third-party所在层级）必须提前存在，Composer 不会自动创建 - 改完后必须手动删除旧
vendor目录，再执行composer install或composer update，dump-autoload无效
改完路径后autoload.php还找不到类？检查这三处
自动加载失效通常不是 Composer 没生成文件，而是路径引用错位。新vendor/autoload.php确实生成了，但你的代码、框架或脚本还在找旧路径。
- 确认
require语句指向正确位置，比如从require 'vendor/autoload.php'改成require 'third-party/autoload.php' - 检查
vendor/composer/autoload_real.php头部是否已更新为新路径，例如__DIR__ . '/third-party/composer/autoload_static.php' - 如果用了 OPCache，需调用
opcache_reset()或重启 PHP-FPM；IDE（如 PhpStorm）也可能缓存旧索引，需手动刷新
别忽略vendor/bin和工具链的连锁反应
vendor-dir一变，vendor/bin就变成third-party/bin，所有依赖该路径的环节都会断掉。
比如你在composer.json里写了"scripts": {"test": "phpunit"}，Composer 默认会在vendor/bin下找phpunit，现在得手动改脚本或加PATH=third-party/bin:$PATH；Laravel 的artisan或 Symfony 的console如果被封装进bin/，也得同步调整入口。
更隐蔽的是安全扫描器、PHPStan/ Psalm 默认只扫vendor/，一换名就跳过依赖分析——这不是 Composer 的问题，是你整个工程链路没对齐。
