Composer如何配置项目的支持链接_在json添加issue和wiki地址【项目文档】

在 composer.json 根对象的 support 字段下添加 issues 和 wiki 子键，值为完整 HTTPS URL，如 "support": {"issues": "https://...", "wiki": "https://..."}，并确保 Packagist 已同步最新配置。

composer.json 里怎么加 issue tracker 和 wiki 链接

虽然 Composer 这个工具本身并不会去解析 issues 或 wiki 字段，但这里有个关键点：主流的 PHP 包仓库 Packagist 会识别它们。只要你在 composer.json 文件的顶层，按照正确的格式写好这两个字段，一旦发布到 Packagist，你的项目页面右上角就会自动出现对应的图标和跳转链接。

配置的位置有严格要求，必须写在根对象下，可别嵌套在 extra 或其他字段里：

{
    "name": "vendor/package",
    "description": "A sample package",
    "homepage": "https://example.com",
    "support": {
        "issues": "https://github.com/vendor/package/issues",
        "wiki": "https://github.com/vendor/package/wiki"
    }
}

• support 是必须使用的外层字段名，大小写敏感，写成 Support 或 support-info 可不行。
• issues 和 wiki 是 support 对象下的子键，它们的值必须是完整且可访问的 HTTPS URL。
• 对于 GitHub 或 GitLab 项目，虽然默认提供了 issues 和 wiki 功能，但路径一定要写全。当然，如果你的仓库禁用了 issues，那么即使填了链接，用户点开也只会看到 404。
• 这里有个小细节：Packagist 并不会主动校验你填的 URL 是否真实可达，它只是原封不动地展示出来。所以，如果地址填错了，最终只会让点击的用户感到失望。

为什么 support.issues 没出现在 Packagist 页面上

配置明明写对了，但 Packagist 页面上就是看不到按钮？最常见的原因其实很简单：你修改了 composer.json，但没有触发 Packagist 的同步。要知道，Packagist 不会自动轮询你的代码仓库，它依赖的是 GitHub/GitLab 的 webhook 通知，或者你的手动更新操作。

• 首先，确认你的 GitHub 仓库是否已经接入了 Packagist 的 webhook。可以到仓库的 Settings → Webhooks 里查看，是否包含来自 packagist.org 的回调地址。
• 如果没有设置 webhook，也别急。直接登录 Packagist，进入个人页面，找到对应的包，点击 “Update” 按钮，强制拉取最新的 composer.json 配置。
• 然后，检查 Packagist 项目页面右上角，在「Source」按钮旁边，是否出现了「Issues」和「Wiki」按钮。如果还是没有，那很可能就是 support 字段的结构没有被正确识别，比如缩进错误、遗漏了逗号，或者不小心用了单引号。
• 运行 composer validate 命令可以快速发现 JSON 语法问题，但要注意，它不会报告 support 字段无效——因为这个字段本身是合法的，只是它的“消费者”是 Packagist，而非 Composer 工具本身。

除了 issues 和 wiki，support 还能填什么

support 字段组是 Packagist 明确支持的一套元信息容器。除了最常用的 issues 和 wiki，它还接受以下这些可选键：

• email：联系邮箱，会显示为一个 mailto: 链接。
• irc：IRC 频道地址，格式例如 irc://irc.freenode.net/#package。
• source：源码仓库地址（通常和 homepage 或 repositories 里的配置一致，Packagist 会优先使用仓库本身的配置）。
• docs：独立的文档站点地址，比如 ReadTheDocs 的链接，这区别于 wiki。
• rss：RSS 订阅源（这个用得比较少）。

需要明确的是，support 下的所有字段都不会影响 Composer 的安装行为，它们纯粹是为了展示项目支持信息。但话说回来，如果用户第一眼看到「Wiki」按钮，兴冲冲点进去却跳转到 404 页面，那可比没有这个按钮更伤信任。

要不要把 issue 模板也塞进 composer.json

答案是：不用，而且也不能。GitHub 或 GitLab 的 issue 模板，是存放在仓库根目录下 .github/ISSUE_TEMPLATE/ 这样的文件系统结构里的，这和 composer.json 的配置完全是两码事。Composer 既不会读取、也不会转发或校验这些模板文件。

如果你希望贡献者在提交 issue 时能自动套用格式，唯一有效的做法是：

• 在 GitHub 仓库中，通过创建 .github/ISSUE_TEMPLATE/bug_report.md 这类文件来启用 issue 模板。
• 确保 composer.json 里 support.issues 指向的是该仓库的 issues 列表主页（例如 https://github.com/vendor/package/issues），而不是某个具体的 issue 链接。
• 别试图用 extra 字段来模拟支持链接——Packagist 会忽略它，用户自然也看不到。

其实，真正容易踩坑的地方往往就三个：字段名的拼写、URL 的可访问性，以及 Packagist 的同步机制。这三者缺了任何一个，你配置的链接就等于白费功夫。