合法填写 Composer 的 license 字段应使用标准 SPDX 许可证标识符（如 MIT、Apache-2.0、BSD-3-Clause），大小写敏感、带连字符和准确版本后缀；禁用模糊缩写、空格、非 SPDX 字符串或错误格式。
license 字段填什么才合法又不踩坑
Composer 的
字段不是装饰，它直接参与依赖合规检查、CI 扫描（比如 Snyk、Dependabot）、甚至影响企业采购决策。填错可能被判定为“未知许可证”，导致整个包被拦截。
合法写法只有两类：
SPDX 许可证标识符
（推荐）或
自定义字符串
（慎用）。别写 “MIT” “Apache2” 这种模糊缩写——
是对的，
或
就是错的。
、
、
：标准 SPDX ID，大小写敏感，带连字符和版本后缀（如
/
）必须准确
或
：仅限内部工具或明确放弃版权的场景，但会触发多数扫描器告警
避免
—— BSD 有 2-clause、3-clause、4-clause 多种，必须写成
或
composer
.json 里 license 和 LICENSE 文件怎么配
字段只是声明，不替代实际许可证文本。Composer 不校验内容一致性，但人类和合规工具会交叉比对。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
如果
填了
，项目根目录必须存在
或
，且内容是标准 MIT 模板（含版权年份和作者）
填
却只放了 GPL-2.0 文本？会被识别为许可证冲突
多许可证项目（如“MIT 或 GPL-3.0”）要写成数组：
，同时 LICENSE 文件需明确说明可选关系
私有包 / 内部工具该不该填 license
应该填，哪怕只是
。不填
字段 ≠ 没有许可证，而是等于“许可证未知”，很多企业 Composer 镜像策略会直接拒绝安装。
表示闭源、无再分发权，适合公司内部 PHP 工具库
别用
或
—— 这些不是 SPDX ID，会被解析为未知类型
如果包未来可能开源，现在就预留标准 ID（如
），并在 README 注明“当前仅限内部使用”
license 字段会影响 packagist.org 展示和搜索吗
会。Packagist 把
当作结构化字段索引，填错会导致：搜索
找不到你的包；页面右上角许可证图标显示为 ❓；API 返回的
值为空或 null。
常见错误：
写成
（单值不用数组）或
（格式错误）
空格和引号必须严格：
✅，
❌（前后空格会导致解析失败）
修改后要
或手动触发 Packagist 同步，缓存可能延迟 10 分钟
事情说清了就结束。最常被忽略的是：改完
字段后没同步 LICENSE 文件内容，或者以为小写
能被自动标准化——它不会。
licenseMITmitMIT LicenseMITApache-2.0GPL-3.0-only-only-or-later"proprietary""unlicensed""BSD"BSD-2-ClauseBSD-3-ClauselicenselicenseMITLICENSELICENSE.mdGPL-3.0-or-later["MIT", "GPL-3.0-or-later"]"proprietary"license"proprietary""internal""company""MIT"licenselicense:MITlicense"license": "MIT""license": ["MIT"]"license": {"type": "MIT"}"license": "MIT""license": " MIT "composer publishlicensemit