“license mismatch”报错非composer默认行为，而是因启用config.license白名单、第三方插件或私有镜像强制拦截所致；需检查composer config license、composer show --plugin，并人工核验license文件全文。
composer install 报 “License mismatch” 或被阻断安装怎么办
这不是 Composer 默认行为，而是你或团队手动启用了 license 检查策略（比如通过 config.license 或第三方插件），或者项目中显式配置了 "require": {"composer-plugin-license-check": "*"} 类插件。Composer 本身不校验许可证兼容性，只管版本约束和依赖图求解。
常见诱因：
- CI/CD 流水线里加了
composer validate --strict并启用 license 校验扩展 - 私有 Packagist 镜像强制拦截 GPL-licensed 包（尤其当项目声明为 MIT 时）
-
composer.json中写了"config": {"license": "MIT"}，某些企业版 Composer 插件会据此过滤
先运行 composer config license 确认当前是否设置了全局 license 声明；再查 composer show --plugin 看是否有 license 相关插件激活。别直接删 lock 文件——它不存许可证信息，删了也解决不了问题。
如何识别某个包实际用的是什么许可证
Composer 不自动下载 LICENSE 文件，但 Packagist 页面和 composer show 输出里会显示 license 字段。注意这个字段由包作者填写，未必可靠，必须人工核对源码根目录下的真实 LICENSE 文件。
实操建议：
- 运行
composer show vendor/package -v，看输出里的license行（例如license: [mit, apache-2.0]） - 去 GitHub/GitLab 仓库主页，打开根目录的
LICENSE或LICENSE.md，确认文本内容与 SPDX ID 一致 - 警惕
license: proprietary或空值 —— 这类包不能用于商用，除非你拿到单独授权 - 对
GPL-2.0-only、AGPL-3.0-only这类强传染性许可证，即使只作 dev dependency，也可能触发合规审查
conflict 字段能防止许可证冲突吗
不能。conflict 只作用于包名和版本号，对许可证类型完全无感知。写 "conflict": {"monolog/monolog": ">=2.0"} 不会阻止 MIT 许可的 monolog 被装，哪怕你项目要求 Apache-2.0。
真正起效的方式只有两种：
- 在 CI 中集成 php-license-checker 或 license-checker，扫描
vendor/下每个包的真实 LICENSE 文件并比对白名单 - 用私有 Packagist 配置
license-whitelist规则，在代理层就拒绝非授权许可证的包入库
别指望 composer.json 里加一行 "license": "MIT" 就能自动拦住 GPL 包——它只是元数据，不参与解析逻辑。
MIT 和 Apache-2.0 混用会有法律风险吗
一般不会。MIT 和 Apache-2.0 都是宽松型许可证，彼此兼容，允许组合使用。但要注意 Apache-2.0 要求你在分发时保留 NOTICE 文件（如果原包提供），而 MIT 没这要求。漏掉 NOTICE 属于违反 Apache-2.0 条款，可能构成违约。
容易被忽略的点：
- 不是所有标 “Apache-2.0” 的包都附带 NOTICE —— 有些只放 LICENSE，有些干脆没 NOTICE 文件，这种可忽略
- 如果你把多个 Apache-2.0 包打包进一个 SDK 分发，得合并所有 NOTICE 内容，不能只留一个
- MIT 包里若引用了 Apache-2.0 子模块（比如某工具包里嵌了
symfony/polyfill），你仍需遵守 polyfill 的 NOTICE 要求
真正危险的是混用 GPL 系列（尤其是 AGPL）和闭源代码，或者把 LGPL 库静态链接进专有二进制——这些场景靠 Composer 配置根本拦不住，必须靠法务介入。
