合法填写 Composer 的 license 字段应使用标准 SPDX 许可证标识符（如 MIT、Apache-2.0、BSD-3-Clause），大小写敏感、带连字符和准确版本后缀；禁用模糊缩写、空格、非 SPDX 字符串或错误格式。
license 字段填什么才合法又不踩坑
Composer 的 license 字段不是装饰，它直接参与依赖合规检查、CI 扫描（比如 Snyk、Dependabot）、甚至影响企业采购决策。填错可能被判定为“未知许可证”，导致整个包被拦截。
合法写法只有两类：SPDX 许可证标识符（推荐）或 自定义字符串（慎用）。别写 “MIT” “Apache2” 这种模糊缩写——MIT 是对的，mit 或 MIT License 就是错的。
-
MIT、Apache-2.0、GPL-3.0-only：标准 SPDX ID，大小写敏感，带连字符和版本后缀（如-only/-or-later）必须准确 -
"proprietary"或"unlicensed"：仅限内部工具或明确放弃版权的场景，但会触发多数扫描器告警 - 避免
"BSD"—— BSD 有 2-clause、3-clause、4-clause 多种，必须写成BSD-2-Clause或BSD-3-Clause
composer.json 里 license 和 LICENSE 文件怎么配
license 字段只是声明，不替代实际许可证文本。Composer 不校验内容一致性，但人类和合规工具会交叉比对。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果
license填了MIT，项目根目录必须存在LICENSE或LICENSE.md，且内容是标准 MIT 模板（含版权年份和作者） - 填
GPL-3.0-or-later却只放了 GPL-2.0 文本？会被识别为许可证冲突 - 多许可证项目（如“MIT 或 GPL-3.0”）要写成数组：
["MIT", "GPL-3.0-or-later"]，同时 LICENSE 文件需明确说明可选关系
私有包 / 内部工具该不该填 license
应该填，哪怕只是 "proprietary"。不填 license 字段 ≠ 没有许可证，而是等于“许可证未知”，很多企业 Composer 镜像策略会直接拒绝安装。
-
"proprietary"表示闭源、无再分发权，适合公司内部 PHP 工具库 - 别用
"internal"或"company"—— 这些不是 SPDX ID，会被解析为未知类型 - 如果包未来可能开源，现在就预留标准 ID（如
"MIT"），并在 README 注明“当前仅限内部使用”
license 字段会影响 packagist.org 展示和搜索吗
会。Packagist 把 license 当作结构化字段索引，填错会导致：搜索 license:MIT 找不到你的包；页面右上角许可证图标显示为 ❓；API 返回的 license 值为空或 null。
- 常见错误：
"license": "MIT"写成"license": ["MIT"]（单值不用数组）或"license": {"type": "MIT"}（格式错误） - 空格和引号必须严格：
"license": "MIT"✅，"license": " MIT "❌（前后空格会导致解析失败） - 修改后要
composer publish或手动触发 Packagist 同步，缓存可能延迟 10 分钟
license 字段后没同步 LICENSE 文件内容，或者以为小写 mit 能被自动标准化——它不会。 
