不能——composer show 默认输出不包含 support 字段，即使 composer.json 中已定义；需用 --format=json 配合 jq 或人工查 JSON 才能获取，且该字段常为空或不可靠。
composer show 能直接看到 support 字段吗
不能——composer show 默认输出里**不包含 support 字段**，哪怕包的 composer.json 里明确定义了 "support": {"issues": "...", "source": "...", "email": "..."} 。这是最常被误以为“应该有但实际没有”的地方。
原因很简单：Composer 官方从未把 support 设为 show 命令的默认展示字段，它只保证输出 homepage、source、autoload 等核心元数据。而 support 属于可选字段，工具层不做强制渲染。
- 查已安装包？运行
composer show vendor/package-name，扫一眼输出，没看到support就说明它没被显示 - 想确认包到底有没有定义 support？得手动看它的
composer.json文件，路径通常是vendor/vendor/package/composer.json - 别指望
--remote或-s能补上这个字段——它们也不管support
怎么绕过限制，真正拿到 support 信息
唯一可靠办法是用 composer show --format=json 拿到原始 JSON，再用 jq 提取（Linux/macOS）或配合其他工具解析（Windows 可用 jq-win64 或 PowerShell）。
-
composer show --format=json monolog/monolog | jq '.support'—— 直接输出 support 对象 - 如果没装
jq，至少先看看完整 JSON：composer show --format=json monolog/monolog | head -30，人工找"support"键 - 注意：有些包把 issue tracker 放在
homepage里（比如指向 GitHub Pages），support.issues反而是空的——这很常见，不是你漏看了
support 字段为什么经常为空或不可靠
因为它是纯手工维护的字段，没人校验，也没自动化填充机制。作者写不写、写不写全、写对不对，全凭自觉。
-
support.email多数时候是摆设，发过去基本石沉大海；真要提 issue，优先走support.issues（GitHub/GitLab 链接） -
support.source和source字段可能重复，也可能不一致——前者是作者“声称”的源码地址，后者是 Composer 实际拉取的仓库地址 - 很多小众包压根没填
support，但homepage或source里藏着真实入口；所以看到support: null别急着放弃，顺手翻翻这两个字段
比 support 更值得盯住的三个字段
实际协作中，support 往往不如这三个字段有用，而且它们都会被 composer show 默认显示：
-
homepage：大概率是文档首页或项目主页，点进去通常能找到 “Get Help” 或 “Community” 入口 -
source：直接指向 Git 仓库（如 GitHub），Issues、Discussions、Pull Requests 全在这里，比 email 靠谱十倍 -
license：决定了你能怎么用、能不能商用、改了要不要开源——遇到纠纷时，它比任何 support 渠道都管用
真正卡住的时候，与其反复刷新空的 support 字段，不如打开 source 链接，点进仓库的 Issues 标签页搜关键词，90% 的问题早有人问过了。
