从Composer变更日志看PHP依赖管理的发展趋势-composer-PHP中文网

composer无官方变更日志页面，changelog.md长期缺失，演进细节散见于release_notes.md、github releases和pr描述；2.0是分水岭，重构解析器与安装器，引入content-hash、强化插件限制、增强lock语义，并随php 8+生态收敛约束能力。

从composer变更日志看php依赖管理的发展趋势

Composer 本身不提供官方的“变更日志”页面供用户按版本逐条查阅；CHANGELOG.md 在其 GitHub 仓库中长期缺失，历史版本更新细节散落在 RELEASE_NOTES.md、GitHub Releases 页面和 PR 描述中——这意味着你无法靠“翻日志”系统性把握演进脉络，必须结合行为变化反推趋势。

Composer 2.0 是分水岭：从“能装”到“装得快、管得住”

2020 年底发布的 Composer 2.0 不是小修小补，它重构了依赖解析器与安装器，直接导致几个关键行为变化：

composer install 默认启用并行下载（--no-plugins 和 --no-scripts 的默认行为也更保守）
锁文件 composer.lock 新增 content-hash 字段，校验 composer.json 内容而非仅结构，防止手动改 JSON 后跳过重解析
依赖解析结果不再缓存于 vendor/composer/installed.json，而是由 composer.lock + 运行时 autoload 机制联合保障一致性
PHP 7.2+ 成为硬性要求，ext-zip 从可选变强制，影响离线构建场景

Plugin 机制被持续收紧：不是不能用，而是不能乱用

自 2.2 起，Composer 明确限制插件的执行时机和权限，尤其针对修改依赖图谱或覆盖安装逻辑的行为：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

插件类必须实现 PluginInterface，且不得在 activate() 中调用 Composer\Installer\InstallationManager::addInstaller()
composer global require 默认禁用插件（需显式加 --with-all-dependencies），防止全局工具污染项目环境
错误提示变得更具体，比如 Plugin is not compatible with Composer 2.x 会附带插件声明的 composer-plugin-api 版本范围

Lock 文件语义增强：从“快照”走向“可验证契约”

2023 年后发布的 2.5+ 版本在 composer.lock 中逐步加入更多元数据字段，目标不是让人类可读，而是支撑自动化验证：

packages-dev 与 packages 分离更彻底，require-dev 中的包不会出现在生产环境 autoloader 中（即使未加 --no-dev）
每个包条目新增 type（如 library、metapackage）、notification-url（用于安全通告集成）
dist 块中开始记录 shasum（而非仅 zipball URL），配合 composer install --prefer-dist --no-progress 可实现确定性、可审计的部署

PHP 8+ 生态倒逼 Composer 行为收敛

PHP 8.1 引入枚举、只读类等特性后，大量包开始声明 "php": "^8.1"，这反过来迫使 Composer 加强约束能力：

composer validate 现在会检查 php 约束是否与当前运行环境兼容（可通过 --no-check-php 跳过）
composer outdated 默认过滤掉与当前 PHP 版本不兼容的候选升级项，避免误报
当 composer.json 中同时存在 require 和 conflict 时，冲突检测提前到 install 阶段而非仅 update，防止低版本 PHP 下装入高版本依赖