合法license字段必须填spdx官方短标识，如mit、apache-2.0、gpl-3.0-only；禁用中文、全大写、空格或完整名称；多许可用or/and连接；私有包应填proprietary；自定义许可须用license-files指向真实license文件。
composer.json 里 license 字段填什么才合法
Composer 不校验许可证内容是否“真实有效”，只认你填的字符串是否符合 SPDX License List 规范。填错会导致 packagist.org 拒绝收录、CI 报 warning，甚至被下游项目扫描工具标为“未知许可”。
必须用 SPDX 官方短标识（如 MIT、Apache-2.0、GPL-3.0-only），不能写中文、不能写“MIT License”或“Apache License 2.0”这种完整名称，也不能拼错（比如 APACHE-2.0 全大写是错的，SPDX 要求大小写敏感）。
-
MIT、GPL-3.0-or-later、BSD-3-Clause是常见且安全的选择 - 多个许可用
AND/OR连接，例如"license": ["MIT", "GPL-3.0-or-later"]表示“双许可”，等价于"license": "MIT OR GPL-3.0-or-later" - 自定义许可证？别填字符串，改用
license-files字段指向项目根目录下的LICENSE或LICENSE.md文件路径
packagist.org 显示“Unknown license”但 license 已填了
最常见原因是：填了非 SPDX 标识，或者用了空格/标点污染字段。Packagist 解析时会严格 trim 并比对 SPDX 列表，哪怕多一个点、少一个连字符都会失败。
检查方式很简单：打开 SPDX 官网列表，搜索你填的内容，必须完全匹配（包括连字符、数字、大小写）。例如：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- ✅ 正确：
ISC、Unlicense、LGPL-2.1-only - ❌ 错误：
isc（小写）、LGPL 2.1（空格+无连字符）、MIT License（带文字） - ⚠️ 注意：
GPL-3.0是旧标识，已废弃；必须用GPL-3.0-only或GPL-3.0-or-later
私有包要不要填 license 字段
要填，而且建议明确写 "license": "proprietary"。这不是可选项，而是避免歧义的关键动作。
不填或留空时，Composer 默认视为“未声明许可”，某些企业合规扫描工具（如 FOSSA、Snyk）会直接报高风险；而 proprietary 是 SPDX 官方认可的合法标识，明确表示“此包不开放源代码，仅限授权使用”。
- 填
proprietary后，composer show vendor/package会显示许可证类型，方便内部审计 - 不要用
closed、private、internal等非 SPDX 字符串，这些会被解析为 unknown - 如果私有包实际混用了 MIT 组件，需在
license-files中附上对应声明，而非靠license字段掩盖
license-files 字段怎么配才真正生效
这个字段只在 packagist.org 页面展示 LICENSE 文件内容，不影响 Composer 安装或依赖解析，但它是法律声明落地的关键一环。
它接受字符串数组，每个元素是相对于包根目录的路径，且文件必须真实存在并被 composer.json 的 files 或自动发现机制包含进发布包（即 composer archive 或 git archive 能打进去）。
- 推荐写法：
"license-files": ["LICENSE", "LICENSE.md"]—— 覆盖常见命名 - 路径不能带
../，不能是绝对路径，不能指向vendor/或生成文件 - 如果用了
autoload.files加载 LICENSE 内容做运行时检查，那是另一回事，和license-files无关
