license字段必须使用spdx官方标识符，单协议写字符串（如"mit"），多协议写数组（如["mit","apache-2.0"]），闭源用"proprietary"；须与根目录license文件内容严格一致，否则packagist不显示徽章、ci报unknown、企业拒收。
license 字段只是元数据，填错不会导致 composer install 失败，但 Packagist 不显示协议徽章、CI 合规扫描报 unknown、企业采购直接拒收——它必须是 SPDX 官方标识符，且和项目根目录的 LICENSE 文件内容严格对应。
composer.json 里 license 字段怎么写才合法
Composer 不校验法律效力，只校验字符串是否在 SPDX License List 中。填错会被当成 proprietary 或直接忽略。
-
license必须是字符串（单协议）或字符串数组（多协议），例如："MIT"或["MIT", "Apache-2.0"] - 大小写敏感：
"mit"可识别，但"MIT "（尾部空格）、"MIT License"、"Apache 2.0"全部非法 - 不能用自然语言、URL、中文、缩写（如
"BSD"）、或带括号的表达式（如"MIT OR Apache-2.0"）——除非你明确启用 SPDX 表达式解析（极少见） - 闭源项目只能写
"proprietary"；"internal"、"unlicensed"、空值、null都会导致工具误判 - 字段必须在
composer.json根级，不能嵌套在require、autoload或其他子对象里
为什么改了 license 却在 Packagist 上不显示
Packagist 不实时同步代码库，它只抓取 tag 对应的 commit。改完 composer.json 后没效果，基本是因为发布流程断了。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须打新 tag（如
v1.3.0），仅 push 到main分支无效 - 确认该 tag 指向的 commit 中，
composer.json的license字段确实存在且拼写正确 - 访问
https://packagist.org/packages/vendor/name，看右上角 “Last updated” 时间；若滞后，点页面上的 “Update” 手动触发同步 - Webhook 失败很常见，别依赖自动推送——尤其私有 GitLab 实例或自建仓库
license 字段和 LICENSE 文件的关系
license 字段本身没有法律效力，真正起作用的是项目根目录下名为 LICENSE（无后缀）或 LICENSE.md 的纯文本文件。
- GitHub/GitLab 页面顶部的协议徽章、FOSSA/Snyk 扫描结果、企业镜像站是否同步，全靠这个文件是否存在、命名是否准确、内容是否为对应 SPDX 协议原文
- 必须用标准协议正文：从 choosealicense.com 复制，或用
curl -sL https://raw.githubusercontent.com/spdx/license-list-data/master/text/MIT.txt > LICENSE - 别写
LICENSE.txt、license.md（小写）、LICENSE.md（Git 忽略了）、或把文件放在docs/子目录下——这些位置 Packagist 和扫描器一律无视 - 多许可证场景下，
LICENSE文件需明确说明选择关系，例如：“This software may be used under the terms of either the MIT License or the Apache-2.0 License.”
CI 中如何自动校验 license 合法性
靠人工核对容易漏，CI 是最后一道防线。重点不是“有没有”，而是“对不对”。
- 运行
composer validate：检查 JSON 结构 + 基础 SPDX 格式（不联网，不查最新列表） - 用
composer show --no-dev --licenses vendor/name确认输出是否为预期值（如MIT），而非???或unknown - 加文件存在性检查：
test -f LICENSE || (echo "LICENSE missing"; exit 1) - 白名单校验（团队强约束）：
composer show --no-dev --format=json | jq -r '.[].license // ["UNLICENSED"] | .[]' | grep -qE '^(MIT|Apache-2.0|BSD-3-Clause)$' || exit 1
composer.json 的 license，却忘了同步更新 LICENSE 文件内容，或者 PR 模板里没强制要求二者同时提交。这类不一致在审计时才会暴露，但代码早已合并进主干。
