composer show vendor/package-name 可直接查看 homepage 字段，但需指定完整包名；若无该字段，则优先查 Packagist 页面，其数据更实时准确，且含自动提取的文档链接与失效提示。
composer show 能直接查到包的 homepage 字段
大多数 Composer 包在 composer.json 里会声明 homepage，这是最接近“官方主页”的字段。运行 composer show vendor/package-name 就能立刻看到，不需要额外解析或跳转。
常见错误是只用 composer show 不带参数，结果列出所有包、信息混杂，根本找不到目标；或者误以为 source 或 dist 的 URL 就是文档页——其实那只是代码分发地址，和文档 / 主页无关。
- 必须指定完整包名（如
monolog/monolog），不能只写monolog - 如果输出里没有
homepage行，说明该包没填这个字段，别硬找 - 有些包把文档放
support→docs字段里，但不普遍，优先看homepage
packagist.org 页面比命令行更可靠
Composer 命令依赖包作者是否规范填写元数据，而 Packagist 网站会聚合 GitHub/GitLab 仓库信息，自动提取 README、wiki 链接，甚至显示“Documentation”标签页。对很多活跃项目来说，这比 composer show 更准。
直接访问 https://packagist.org/packages/vendor/package-name，比如 https://packagist.org/packages/guzzlehttp/guzzle，页面右上角的“Source”、“Homepage”、“Support”都是人工或自动填充的入口。
- 注意区分“Homepage”和“Source”：前者通常是官网或文档站，后者是代码仓库（GitHub）
- 有些包在“Support”→“Issues”旁有“Docs”链接，点进去才是真实文档地址
- 如果包已弃用（abandoned），Packagist 会显眼提示并推荐替代包，命令行完全不体现这点
composer info -s 查不到文档链接时怎么办
composer info -s 只显示源码路径，跟文档无关；很多人搜“composer doc url”会误试这个命令。真要定位文档，得换思路：看包是否自带 docs/ 目录、是否有 .readthedocs.yaml、是否在 README 顶部写了文档链接。
最省事的办法是进 vendor 目录手动翻：cat vendor/vendor/package-name/README.md | head -20，90% 的主流包会在前几行放文档链接。
- 不要依赖
composer search，它只匹配包名和描述，不查内容 - GitHub 上搜
repo:vendor/package-name "documentation" OR "docs"往往比 Composer 命令更快 - 有些包（如 Laravel 生态）把文档全托管在 laravel.com，不在包内，必须认准官方域名
为什么 packagist.org 比 composer show 更值得信任
因为 composer show 显示的是本地 vendor/composer/installed.json 里的缓存数据，它来自安装时的 composer.json 快照——如果作者后来更新了 homepage，但你没 composer update，就永远看不到新地址。
Packagist 则实时抓取最新 composer.json，且会校验 GitHub 仓库的 README 是否含文档锚点（比如 [Docs](https://……)），还会索引 phpdoc 生成的 API 页面。
- 本地命令查到的链接可能已 404，Packagist 页面会标出“Link is broken”提示
- 某些包（如 Symfony 组件）在 Packagist 上有“Official Documentation”专用按钮，直连 symfony.com
- 如果你用的是私有包，Packagist 不适用，这时只能靠内部 Wiki 或强制约定 README 头部格式
真正麻烦的不是找不到链接，而是包作者根本没填 homepage、也没在 README 里写文档地址——这种时候，唯一靠谱的动作是去 GitHub 仓库的 Issues 里搜“docs”，或者看最近 PR 的标题有没有“Update docs link”。
