support 字段必须包含 issues、source、email 三个键：issues 指向工单系统完整 URL（如 /issues 路径），source 指向源码主页，email 作备用联系渠道且需确保响应。
support 字段在 composer.json 中不参与依赖解析或安装流程，纯属元信息，但它是用户首次接触包时最常看到的“求助入口”——填错或留空，等于把报错用户直接推给 GitHub Issues 页面硬找。
support 字段必须包含哪些键？
Composer 官方只定义了 4 个可识别的子键：email、issues、source、forum、wiki、irc、twitter（见 Composer Schema 文档），但实际被广泛消费的只有前三个：
-
issues：指向工单系统（如 GitHub/GitLab 的 Issues 页面），必须是完整 URL，且建议带/issues路径而非仓库首页 -
source：指向源码地址（如 GitHub 仓库主页），用于composer show -s vendor/package展示，不是下载源 -
email：仅作备用联系渠道，不建议设为个人邮箱；若用，需确保能及时响应或自动转发到工单系统
其余键（如 forum）极少被工具链读取，填了也基本没人看。
工单系统链接怎么配才不会失效？
GitHub 和 GitLab 是主流场景，但链接写法直接影响用户点击后的体验和维护成本：
- 用
https://github.com/vendor/package/issues，别用https://github.com/vendor/package—— 后者进的是代码页，用户还得手动点 Issues 标签 - GitLab 项目若启用了自定义 Issue 模板，确保
issues链接末尾不带/new，否则新用户可能误以为只能提模板内限定类型的问题 - 私有包若用内部 Jira 或 Tapd，URL 必须可被开发者网络直连；若需登录才能访问，得在
README.md里额外说明，composer.json不支持条件跳转
文档链接该放官网还是 README？
composer.json 本身不支持 docs 键，常见做法是塞进 homepage 或 support.wiki，但效果差：
-
homepage通常被 Packagist 显示为“项目主页”，适合放官网；若放 README 链接（如https://github.com/vendor/package/blob/main/README.md），用户点进去看到的是原始 Markdown 源码，体验断裂 -
support.wiki多数工具不识别，Packagist 和 Composer CLI 均不展示 - 真正靠谱的做法：把文档入口统一收口到
homepage，并在官网首页显眼位置提供 API 文档、快速开始、常见问题三类直达链接——composer.json只负责引到“第一站”，不越级管二级导航
很多人花时间调 support 字段格式，却忽略一个事实：Packagist 页面上它只占两行小字，真正决定用户是否愿意提 Issue 的，是点进去后看到的第一个 Issue 模板是否清晰、最近 5 条 Issue 是否有回复、.github/ISSUE_TEMPLATE 里有没有写明「请附 composer show vendor/package 输出」——字段只是门牌号，门后有没有人开门，得靠流程兜住。
