Composer 的 license 字段仅作元数据声明，不影响依赖安装；必须使用 SPDX 标准 ID（如 MIT、Apache-2.0），多协议用 OR/AND 连接，需与 LICENSE 文件内容一致，私有项目推荐填 proprietary。
Composer 项目中的 license 字段不参与依赖安装或自动校验，它纯粹是元数据声明，用于向使用者（人或工具）表明项目遵循的开源协议 —— 填错、留空、写非标准值都不会导致 composer install 失败，但会影响合规性扫描、包管理平台识别和团队协作信任。
license 字段支持哪些值？标准 SPDX ID 是唯一推荐写法
Composer 官方明确推荐使用 SPDX License List 中的标准标识符，例如 MIT、Apache-2.0、GPL-3.0-only。这些字符串会被 Packagist、GitHub、FOSSA、Snyk 等工具准确识别并归类。
以下写法不被推荐：
-
"license": "MIT License"—— 非 SPDX 标准，Packagist 不识别为 MIT 协议 -
"license": "see LICENSE file"—— 工具无法解析，等同于未声明 -
"license": ["MIT", "GPL-3.0"]—— 多协议需用OR或AND显式连接，否则被视为无效数组
正确多协议写法（表示“MIT 或 GPL-3.0”）：
{
"license": "MIT OR GPL-3.0-only"
}
如何验证 license 值是否被 Packagist 正确识别？
Packagist 是 Composer 生态事实上的元数据枢纽，它的识别逻辑直接决定协议信息是否“生效”。验证方法很简单：
- 提交
composer.json后访问对应包页面（如https://packagist.org/packages/vender/name） - 查看右上角显示的协议徽章（如
MIT），点击可跳转 SPDX 页面 - 若显示
unknown或空白，说明license值未被识别 —— 大概率是拼写错误或用了非 SPDX 字符串
常见拼写陷阱：
-
APACHE-2.0❌（全大写带连字符）→ 应为Apache-2.0✅ -
GPL v3❌ → 应为GPL-3.0-only或GPL-3.0-or-later✅ -
BSD❌（太模糊）→ 推荐明确写BSD-3-Clause✅
license 字段与 LICENSE 文件的关系
license 字段只是声明，LICENSE（或 LICENSE.md）文件才是法律效力载体。两者必须一致：
- 若
composer.json写"license": "MIT"，项目根目录必须存在完整 MIT 协议文本文件 - 若协议有例外条款（如“仅限非商业用途”），SPDX 不支持该语义，此时
license应设为proprietary，并在LICENSE文件中详述限制 - 某些公司合规流程会强制检查：SPDX ID 是否存在对应 LICENSE 文件，缺失则阻断发布
注意：composer.json 不提供自动同步 LICENSE 文件内容的功能，全靠人工维护一致性。
私有项目要不要填 license？填什么？
私有项目仍建议显式填写，理由很实际：
- 避免下游扫描工具误报“未声明协议”，干扰安全/合规报告
- 内部审计时，
proprietary比空值更能体现主动治理意识 - 若未来可能开源，提前按 SPDX 规范填写可省去迁移成本
可选值参考：
-
"license": "proprietary"—— 最通用的私有声明，SPDX 官方认可 -
"license": "unlicensed"—— 表示无任何授权（慎用，等同于保留所有权利） - 完全不填 —— 工具通常默认为
unknown，不如明确写proprietary
真正容易被忽略的是：团队成员在 fork 或复制模板项目时，常直接复用原 license 字段却不更新 LICENSE 文件内容 —— 这会导致声明与实际法律文本脱节，比不填更危险。
