vendor 目录不是“放包的地方”——它是 Composer 依赖隔离与自动加载的物理载体，结构即逻辑，路径即命名空间。删了它能重建，但乱动里面文件会直接破坏自动加载。
vendor 目录路径为什么是 vendor/monolog/monolog 这种双层结构？
这是 Packagist 上包的 name 字段硬编码生成的，比如 monolog/monolog 就会解压到 vendor/monolog/monolog；symfony/http-foundation 对应 vendor/symfony/http-foundation。
关键点：
厂商名和包名必须全部小写，大小写不一致会导致路径错位、类找不到这个结构不可自定义重命名，改 composer.json 中的 name 字段只会让下次安装走新路径，旧目录不会自动清理PSR-4 自动加载时，Composer 会把该包 autoload 配置里的命名空间前缀（如 Monolog\）和它所在目录（vendor/monolog/monolog/src/）绑定
autoload.php 和 vendor/composer/ 下的文件谁在管加载？
vendor/autoload.php 是唯一入口，但它本身不包含映射逻辑，只是引导器；真正干活的是它 require 的那一堆 vendor/composer/autoload_*.php 文件。
这些文件由 Composer 根据所有已安装包的 autoload 配置（PSR-4、classmap、files）动态生成，其中：
autoload_real.php 是运行时调度中心autoload_static.php 是启用 "optimize-autoloader": true 后生成的静态映射表，性能更好，但改了类后必须手动 composer dump-autoload删掉整个 vendor/composer/ 目录会导致 Class not found，哪怕所有包文件都还在——因为映射元数据没了
为什么不能改 vendor 目录位置，或者把它挪进 public/ 下？
vendor 是 Composer 硬编码的默认依赖安装路径，不是靠配置“选出来”的。即使你在 composer.json 里写了 "config": { "vendor-dir": "libs" }，它也只在 vendor 不存在时生效，且后续会有连锁问题：
vendor/bin/ 下的可执行文件路径会变，脚本调用可能失败IDE、PHPStan、Psalm 默认扫描 vendor/，改路径后需手动调整配置Web 入口（如 public/index.php）里写的 require __DIR__.’/../vendor/autoload.php’ 必须同步改，否则启动就报错CI/CD 脚本、Dockerfile 通常硬编码 vendor/，改了就得全量更新
vendor 目录该不该提交到 Git？删了之后怎么恢复？
vendor 必须被 .gitignore 排除，composer.lock 却绝不能丢。
原因很实在：
vendor 是构建产物，内容由 composer.lock 精确决定；重复提交只会制造冲突、增大仓库体积删掉 vendor 后，只要保留 composer.lock，运行 composer install 就能 100% 复原原始依赖状态如果只运行 composer update，会重写 composer.lock，破坏环境一致性——生产部署必须用 composer install –no-dev –optimize-autoloader
最常被忽略的一点：很多团队误以为 vendor 是“源码一部分”，于是手动修改包内文件来“临时修复 bug”。下次 composer update 或 install 会直接覆盖，所有改动丢失，还可能引入不兼容变更。
评论(0)