support.issues 是纯元信息字段，不参与依赖解析，必须配置为指向托管平台 Issues 主页的完整可访问 URL，如 https://github.com/user/repo/issues；其他 support 字段如 email、forum、source 等也仅用于展示，不影响安装。
Composer 项目中的 support 字段不参与依赖解析或安装流程，它纯粹是元信息，但正确配置能显著提升协作效率和用户信任度——尤其是 Bug 追踪链接（issues）被 GitHub/GitLab 等平台直接识别后，composer show、Packagist 页面、IDE 插件（如 PHPStorm 的 Composer support）都会展示可点击的入口。
support.issues 必须是完整、可公开访问的 URL
不是路径，不是相对地址，也不是项目主页。常见错误是填成 ./issues、https://github.com/username/repo/blob/main/ISSUE_TEMPLATE.md（指向模板文件而非 issues 列表页），或漏掉 https:// 导致解析失败。
正确写法只有一种：指向托管平台的 Issues 主页，例如：
{
"support": {
"issues": "https://github.com/myorg/mypackage/issues"
}
}
- GitHub 项目：用
https://github.com/{user}/{repo}/issues - GitLab 项目：用
https://gitlab.com/{group}/{project}/-/issues（注意/-/issues是标准路径） - 自建平台（如 Gitea）：确保该 URL 返回 200 且无需登录即可查看列表
support 字段支持的其他键值对及其作用
support 是一个对象，除 issues 外，常用字段还有：
-
email：用于紧急安全问题联络，如"security@myorg.com"（非必填，但建议提供） -
forum：社区讨论区链接，如 Discourse 或自建论坛 -
source：代码仓库地址（通常与repositories或 Packagist 自动发现一致） -
docs：文档站点，如"https://mypackage.myorg.dev/docs" -
rss：更新 RSS 源（极少用）
注意：support 中任意字段都不影响 Composer 安装行为；但 Packagist 会抓取并展示所有有效字段，issues 和 source 尤其关键。
验证 support.issues 是否生效的三个方法
改完 composer.json 后别只靠肉眼检查，用以下方式确认是否被正确识别：
- 运行
composer show myorg/mypackage --verbose，输出中应包含Support: issues => https://... - 提交到 GitHub 后，等待 Packagist 自动更新（或手动 trigger sync），打开对应包页面，看 “Support” 区域是否显示 Issues 链接
- 在 PhpStorm 中右键项目 → “Composer” → “Show Package Information”，检查 Support 栏
如果链接未出现，优先检查：composer.json 是否语法合法（用 composer validate）、是否已推送到默认分支、Packagist 是否绑定了正确的仓库 URL。
真正容易被忽略的是：即使 support.issues 配置正确，若仓库本身关闭了 Issues 功能（GitHub 上仓库 Settings → Features → Issues = disabled），那么链接虽然能点开，但实际 404 —— 所以配置前务必确认平台侧功能已启用。
