Composer安装的包默认位于执行composer install命令时的当前工作目录下的vendor/文件夹中；因为Composer只认shell的pwd路径，不识别项目结构，故在子目录（如public/）执行会导致vendor错位，且vendor/monolog/monolog等双层路径由包name字段硬编码生成，大小写敏感、不可手动修改。
Composer安装的包默认就在你执行composer install时所在的当前工作目录下的vendor/文件夹里，不是项目根目录、不是用户家目录、也不是PHP安装目录——就是你敲命令那个位置。
为什么vendor/总在当前目录下，而不是项目根目录？
因为 Composer 不识别“项目结构”，它只认pwd（当前 shell 工作路径）。常见错误是：你在public/或src/子目录里执行composer install，结果vendor/被建在public/vendor/，而入口脚本还在上层，require 'vendor/autoload.php'立刻报错。
- 运行
pwd确认当前路径，再执行composer install - 不要依赖 IDE 或编辑器自动跳转到“项目根目录”再操作——终端 pwd 才是唯一可信依据
- CI/CD 脚本中务必用
cd /path/to/project && composer install显式切换，避免路径漂移
vendor/monolog/monolog这种双层路径是怎么来的？
它完全由 Packagist 上包的name字段硬编码生成，比如"name": "monolog/monolog" → 目录就是vendor/monolog/monolog/。这不是约定，是源码级强制规则。
- 大小写敏感：
Monolog/monolog会建错目录，PSR-4 映射失效，new Monolog\Logger直接Class not found - 空格、下划线、点号都不允许；只有小写字母、数字、短横线、斜杠合法
- 手动重命名
vendor/monolog/monolog为vendor/monolog/Monolog没用——下次composer update会覆盖回原名
怎么快速确认某个包的本地绝对路径？
别猜、别翻文件夹、别靠 IDE “跳转到定义”——它可能因 autoload 未重建而失效。最稳的是用 Composer 自带命令：
- 先确保包已在
composer.json的require或require-dev中，且已执行过composer install - 运行
composer show -p vendor/package-name（必须加-p），例如：composer show -p guzzlehttp/guzzle - 输出结尾带
/，比如/your/project/vendor/guzzlehttp/guzzle/，后面直接拼src/Client.php就能打开源码 - 如果报
Package not found，不是命令错了，是包根本没装进去——检查composer.json拼写和composer install是否真执行成功
镜像只是加速下载，不影响vendor/位置和结构
阿里云、腾讯云、华为云等 Composer 镜像只改packagist.org的请求地址，不改变任何本地路径逻辑。换镜像后vendor/还是原来那个位置，包目录结构也完全不变。
- 配置镜像用
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 镜像失效或配置错误，只会导致
composer install卡住或报网络错误，不会让vendor/变位置、也不会让autoload.php失效 - 真正影响加载的是
vendor/composer/autoload_*.php这些映射文件——它们删了或损坏，才需要composer dump-autoload来救
最易被忽略的一点：即使你用COMPOSER_VENDOR_DIR环境变量把vendor/挪到别处，或者用了installer-paths把某些包单独放，composer show -p仍能返回正确路径——但 IDE 和静态分析工具默认只扫描字面路径vendor/，不会自动跟进你的自定义配置。
