composer install本地能过而ci卡住，根本原因是ci启用了--strict-licenses校验且配置了config.license白名单，而本地未启用该参数；--strict-licenses必须显式指定才触发校验，且config.license须严格按spdx id小写数组格式置于config子键下，否则无效。
企业代码提交流程中加开源协议卡点，不是靠 Composer 自动拦截，而是靠 composer install --strict-licenses + config.license 白名单 + CI 阶段强制校验三者配合实现。单独配置任何一项都无效。
为什么 composer install 本地能过、CI 却卡住？
根本原因不是网络或镜像问题，而是 CI 环境启用了严格协议检查，而本地没开。
-
composer install默认完全不读config.license，也不校验依赖 license 字段 - 只有显式加
--strict-licenses参数才会触发校验逻辑 - 企业 CI 脚本里通常写的是
composer install --no-dev --optimize-autoloader --strict-licenses，但开发人员本地执行时往往漏掉--strict-licenses - 如果
composer.json里没配config.license数组，加了--strict-licenses会直接报错：“No allowed licenses configured”
config.license 必须写对位置和格式
写错路径或结构，--strict-licenses 就视而不见，等于没设白名单。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 正确路径是：
"config": { "license": ["mit", "apache-2.0", "bsd-3-clause"] }—— 注意license是config的子键，不是顶层字段 - 值必须是字符串数组，不能是单个字符串（
"license": "mit"无效） - 元素必须是 SPDX 官方 ID，全小写、用连字符（
"mit"✅，"MIT"❌，"MIT License"❌，"https://..."❌） - 数组内任意一个 ID 匹配上依赖的
license字段（字符串或数组），即算通过；不要求全部匹配
CI 中如何可靠触发卡点？
不能只靠命令参数，得把校验动作固化进流水线，避免绕过。
- 在
.gitlab-ci.yml或Jenkinsfile中明确写死composer install --strict-licenses，别封装成别名或变量 - 加前置检查：
test -f composer.lock || (echo "composer.lock missing" && exit 1)—— 没 lock 文件就拒绝运行，防止composer update在 CI 中偷偷执行 - 避免在 CI 中跑
composer update：它会重新解析依赖并生成新 lock，可能引入未审核的协议组合 - 若用自定义合规插件（如
composer/license-checker），确认它是否真正读取config.license，有些插件只查composer show输出，不走原生校验路径
最容易被忽略的一点：白名单只作用于已安装包的 composer.json 中 license 字段值，而这个字段由上游作者自由填写，不校验真实性。你看到 "mit"，不代表对应包真有 MIT 文本，更不代表没混入 GPL 片段——卡点只是拦住了明显违规的字符串，不是法律兜底。
