vendor目录是Composer依赖隔离与自动加载的物理载体，其双层路径（如vendor/monolog/monolog）由packagist包名硬编码生成，直接映射name字段；autoload.php依赖vendor/composer/下动态生成的映射文件，删除后需dump-autoload修复。
vendor 目录不是“放包的地方”——它是 Composer 依赖隔离与自动加载的物理载体，结构即逻辑，路径即命名空间。删了它能重建，但乱动里面文件会直接破坏自动加载。
vendor/monolog/monolog 这种双层路径是怎么来的
这是由 Packagist 上包的 name 字段硬编码生成的，比如 monolog/monolog 的 name 就是这个字符串，Composer 不做任何转换，直接以 / 为分隔符创建两级子目录。
- 如果包名是
acme/utils，目录就是vendor/acme/utils - 厂商名（vendor name）和包名（package name）必须全部小写，大小写不一致会导致路径错位、类找不到
- 这个结构不支持自定义重命名，
composer.json中的name字段改了，安装时就会用新名字建目录，旧目录不会自动清理
autoload.php 和 vendor/composer/ 下的文件谁在管加载
vendor/autoload.php 是唯一入口，但它本身不包含实际映射逻辑；它只是引导器，真正干活的是 vendor/composer/autoload_real.php 和一堆 autoload_*.php 文件。
-
autoload_real.php是运行时调度中心，根据composer.json中的autoload配置（PSR-4、classmap 等）加载对应规则文件 -
vendor/composer/autoload_static.php是启用"optimize-autoloader": true后生成的静态映射表，比 PSR-4 查找快，但修改类后需手动composer dump-autoload - 删掉
vendor/composer/整个目录会导致Class not found，即使包文件还在——因为映射元数据没了
为什么不能把 vendor 移到别的目录或改名
因为 vendor 是 Composer 硬编码路径，不是配置项。所谓 "config": {"vendor-dir": "libs"} 虽然存在，但会引发一连串隐性断裂：
- IDE（如 PHPStorm）默认只索引
vendor/，改路径后跳转、补全失效 - 静态分析工具（PHPStan、Psalm）默认扫描
vendor/，不加额外配置就报“未找到依赖类型” - CI 脚本、部署脚本、Dockerfile 大多写死
vendor/autoload.php，改了就得全局搜改 -
vendor/bin/下的命令（如phpunit）内部硬编码了相对路径，移走后执行直接报错
vendor 目录里哪些文件真能删，哪些碰都不能碰
整个 vendor/ 可以整体删，但局部删要非常小心——有些文件看着无用，实则是自动加载链上的关键环节。
- 可安全删：
vendor/{包名}/.git、vendor/{包名}/tests/（除非你在跑测试）、vendor/{包名}/docs/ - 绝不能删：
vendor/autoload.php、vendor/composer/全部内容、vendor/{包名}/composer.json（部分包靠它做 autoload 注册） - 谨慎删：
vendor/{包名}/CHANGELOG.md看似文档，但某些包的 autoloader 会读它触发版本检查逻辑
最稳妥的做法永远是：删整个 vendor，然后 composer install ——只要 composer.lock 在，结果完全可重现。想省事而局部清理，反而容易踩进 autoload 失效的坑里。
