vendor目录名不能改，是Composer设计契约的刚性体现：autoloader、bin脚本、插件及lock文件均硬编码“vendor”字符串，改名将导致autoload失效、脚本中断、工具链断裂。
vendor 目录名不能改——不是限制，是设计契约的刚性体现。 它不是“默认值可覆盖”，而是 Composer 自动加载、命令执行、依赖解析三者耦合的锚点。改名后 autoload.php 读不到映射表、composer dump-autoload 生成路径错乱、vendor/bin 下脚本直接失效，这不是报错能提示的问题，是整条链静默断裂。
为什么 vendor 这个字符串在代码里到处硬编码
Composer 的 autoloader 初始化、bin 脚本生成、插件注册、甚至 composer.lock 的文件路径记录，都基于 vendor 这个字面量做拼接和校验。例如：
-
vendor/autoload.php是唯一入口，所有框架和脚本（如 Laravel 的artisan）都写死 require 它 -
vendor/composer/autoload_real.php内部构造路径时用的是dirname(__DIR__) . '/vendor'，不是配置读取 -
composer install执行时，会检查vendor/是否存在并可写；若目录名是libs，它不会自动 fallback 或重定向
config.vendor-dir 只能改路径，不能改目录名
这个配置项的作用是把整个 vendor/ 目录“挪位置”，但目录名仍必须是 vendor。比如设为 "vendor-dir": "lib"，实际生成的是 lib/vendor/，而非 lib/。
- 原因：Composer 的 bin 脚本（如
vendor/bin/phpunit）启动时，会向上找第一个vendor/autoload.php，路径逻辑固定为dirname(__DIR__) . '/vendor/autoload.php' - 如果你设成
"vendor-dir": "lib"却期望lib/autoload.php存在，那脚本会找不到入口，报failed to open stream -
COMPOSER_VENDOR_DIR=lib composer install效果相同，最终仍是lib/vendor/，不是lib/
改名后最常被忽略的断裂点
表面看只是目录名变了，实际影响的是运行时上下文和工具链共识：
-
psalm、phpstan默认扫描vendor/，不改配置就跳过全部第三方类型检查 - IDE（如 PHPStorm）索引基于物理路径，旧
vendor/缓存未清，新目录不识别，Ctrl+Click失效 -
composer-patches插件在 apply 补丁前会校验目标路径是否存在vendor/{vendor}/{package}，名字不对直接跳过 - 某些 CI 镜像（如
php:8.3-cli）自带composer global，其~/.composer/vendor/不受项目级vendor-dir影响，但本地开发若混用，容易误判环境一致性
真正卡住的从来不是“能不能删掉再重建”，而是所有外部工具、脚本、IDE 和部署流程，都默认 vendor 是一个不可协商的符号——它既是路径，也是契约。试图绕过，代价是持续对齐所有环节，而不是改一个名字那么简单。
