Composer 的 support 字段仅作为元数据展示，必须使用 email、issues、source、docs、rss 五个大小写敏感键名，其中 issues 和 source 建议必填且需完整 HTTPS URL，validate 仅校验格式不验证可访问性。
Composer 项目中的联系信息不用于自动通信，只作为元数据展示在 Packagist 等平台，但必须写在 composer.json 的 support 字段下，且仅接受特定键名。
support 字段只支持固定几个子键
Composer 官方强制校验 support 对象的结构，只允许以下键名（大小写敏感，多一个或拼错都会导致 composer validate 失败）：
-
email：字符串，建议用项目维护邮箱而非个人邮箱 -
issues：URL，指向 issue 跟踪地址（如 GitHub Issues） -
source：URL，指向源码仓库（如 GitHub/GitLab 仓库主页） -
docs：URL，指向文档站点 -
rss：URL，指向 RSS 订阅源（极少用） -
forum、chat、wiki等非标准键会被忽略或报 warning
错误示例（会触发警告）：
{
"support": {
"contact": "admin@example.com",
"slack": "https://example.slack.com"
}
}
正确写法：
{
"support": {
"email": "support@myproject.org",
"issues": "https://github.com/user/myproject/issues",
"source": "https://github.com/user/myproject"
}
}
email 不是必填项，但 issues 和 source 建议都提供
Packagist 显示页面会优先渲染 issues 和 source 链接，点击即可跳转；email 仅文本展示，无 mailto 链接。实际效果取决于平台解析逻辑：
- 不填
email不影响发布，但用户反馈渠道变少 - 只填
email而不填issues，Packagist 可能不显示“Report Issues”按钮 -
source缺失时，Packagist 无法生成“Source”标签页，影响可信度
validate 会检查 URL 格式但不验证可访问性
composer validate 仅校验 issues 和 source 是否为合法 URL（含协议头），不会发起 HTTP 请求。常见疏漏：
- 写成
"issues": "github.com/user/repo/issues"（缺https://）→ 校验失败 - 误写为
"source": "./src"（本地路径）→ 校验失败 - 使用短链（如
bit.ly/xxx）→ 校验通过，但 Packagist 可能拒绝收录
推荐始终用完整 HTTPS 地址，尤其是 GitHub/GitLab 默认 HTTPS 地址。
注意：support 是纯静态字段，Composer 安装时完全不读取它；它的唯一作用是让 Packagist、GitHub Marketplace 或 IDE 插件等工具在展示包信息时有据可依。别指望它触发任何自动化行为——比如发邮件、创建 issue 或跳转聊天室，那些都得靠人手动操作。
