composer show vendor/name --path是最准的路径来源，直接读取vendor目录真实结构输出带斜杠的绝对路径，需在项目根目录运行、包名严格匹配且composer≥2.2。
composer show vendor/name --path 是最准的路径来源
它不查配置、不拼字符串、不猜结构，直接读 vendor 目录下真实解压后的包位置，输出带结尾斜杠的绝对路径，比如 /var/www/myapp/vendor/monolog/monolog/。这个路径你能直接 cd 进去，也能粘贴进 VS Code 或 PhpStorm 打开。
但前提是：必须在项目根目录（含 composer.json 的目录）运行；包名大小写和斜杠必须完全一致（monolog/monolog ≠ Monolog/Monolog）；Composer 版本 ≥ 2.2。旧版本会报 Unrecognized option "--path"，别硬试，换方案。
查不到？先验证三件事：包名、安装状态、作用域
报 Package not found 不代表命令错了，大概率是环境没对上：
-
composer show看列表里有没有那个包——它只显示真正装进vendor/的包，require-dev里写了但用了--no-dev就不会出现 - 全局安装的包（如
laravel/installer）必须用composer global show laravel/installer --path，普通show完全看不到 - 路径存在但 IDE 跳不到类？不是
--path错了，是vendor/autoload.php没刷新，跑一次composer dump-autoload或composer install
路径找到了，然后呢？别混淆“目录”和“类文件”
--path 返回的是包根目录，不是 GuzzleHttpClient 对应的 src/Client.php。具体类落在哪，得看它的 autoload 配置：
- 运行
composer show -s guzzlehttp/guzzle，找类似"GuzzleHttp\": "src/"的映射 - 有些包把代码放在
lib/、src/、甚至src/GuzzleHttp/下，不能靠经验猜 - 路径本身可用来检查文件是否存在、确认是否为 symlink 版本，但千万别手动改里面代码——下次
composer update会被覆盖
替代方案只在特定场景有用
当 --path 不可用（比如旧版 Composer），才考虑这些：
- 用
composer config vendor-dir --absolute拿到 vendor 根路径，再手动拼/vendor-name/package-name；注意某些项目用composer/installers把包装到了wp-content/plugins/这类非 vendor 目录，--path仍能返回正确位置，但config vendor-dir就不管用了 - 查
vendor/composer/installed.json的install-path字段——但它不实时更新，删了vendor/没重装时还是旧路径；而且几百个包混在一起，grep容易漏掉同名不同 vendor 的条目 - 批量查多个包？别用
--path循环，改用composer show -f json | jq '.packages[] | select(.name=="monolog/monolog") | .install-path'，更稳定
真正容易被忽略的是：路径和自动加载是两件事。你看到的路径只是磁盘位置，而 new Client() 能否成功，取决于 autoload_static.php 里注册的前缀映射是否生效、是否被 dump-autoload 刷新过。
