选MIT、Apache还是GPL取决于你最怕什么：MIT允许闭源商用，Apache含专利报复条款，GPL要求衍生品开源；composer.json的license字段须与LICENSE文件一致，用composer show查真实依赖协议。
MIT、Apache、GPL 选哪个，取决于你最怕什么
不是看哪个“听起来更开源”，而是看你能否接受别人把你的代码拿去闭源卖钱、改名上市、甚至反过来告你侵权。MIT 最不怕这些；GPL 最怕别人不开放；Apache 则在中间补了一道专利防火墙。
选
：你只想让人用，不强求回馈，也不介意大厂把你代码塞进黑盒产品里——React、Vue、Laravel 核心组件都这么干
选
：你希望别人能商用、能改，但得防一手——如果对方起诉你专利侵权，那他自动失去本许可证授权（即“专利报复条款”）
选
：你坚持所有衍生品必须开源，哪怕只是动态链接（GPLv3 对 SaaS 使用有模糊地带，但比 GPLv2 更严），适合构建自由软件生态的底层工具
composer
.json 里 license 字段怎么填才不算瞎写
它不是法律文件，但写错会误导协作者、触发合规扫描误报、甚至让私有项目被误当成可商用开源库。
必须和项目根目录的
（或
）文件内容一致——不能
却放一份 GPL 文本进去
多许可用数组：
表示“任选其一”，不是“同时满足”
闭源内部项目别留空或写
，老老实实写
或
别抄错 SPDX 标识符：是
，不是
或
；Packagist 能识别标准值，乱写会导致展示为 “Unknown”
怎么确认你依赖的包到底用的是什么协议
是唯一靠谱的本地命令，它读的是
里真实安装的包的
，不是 Packagist 缓存，也不是 lock 文件里的快照。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
先确保已运行过
，否则
为空，
会报
查单个包：
→ 看输出里的
行
批量导出（需
）：
注意兜底逻辑：
比
可靠，能处理字段缺失、
、或数组型值（如
）
生成 LICENSE 文件别靠手动复制粘贴
手敲容易漏年份、拼错作者名，还可能混入 Windows 换行或不可见字符，导致自动化合规工具解析失败。
推荐用官方源下载：
需要带变量？用
（Node.js 环境）
CI/CD 中生成
？别硬编码
，改用模板注入：
，再配合
或
替换
改完
的
字段后，务必同步更新
文件和
里的声明，三者不一致才是真坑
许可证不是填完就完的事——它和
文件、
、CI 构建流程、甚至法务尽调都连着。一个
写成
，可能让整个交付物卡在客户合规审查环节。
MITApache-2.0GPL-3.0-onlyLICENSELICENSE.md"license": "MIT""license": ["MIT", "Apache-2.0"]"MIT""proprietary""unlicensed"BSD-3-ClauseBSD3bsd-3composer showvendor/composer.jsoncomposer installvendor/composer showPackage not foundcomposer show monolog/monologlicense:jqcomposer show --no-dev --format=json | jq -r '.packages[] | "\(.name) \(.license // "UNKNOWN")"'.license // "UNKNOWN"grep licensenull["MIT", "Apache-2.0"]curl -sL https://raw.githubusercontent.com/spdx/license-list-data/master/text/MIT.txt > LICENSEnpx license-generator mit --fullname "Your Name" --year "2026" --output LICENSEcomposer.json"license": "MIT""license": "${LICENSE:-proprietary}"sedjqcomposer.jsonlicenseLICENSEREADME.mdLICENSEREADME.mdproprietaryMIT