Composer 2.x 与 1.x 不兼容，lock 文件含 "plugin-api-version" 字段致 1.x 报 fatal error；依赖解析改用 SAT 求解器，速度提升 2–5 倍；并行下载默认开启，受 parallel-downloads 控制；单包升级必连带更新依赖，不支持灰度部署。
Composer 2.x 的 lock 文件结构不兼容 1.x
Composer 2.x 生成的 composer.lock 文件包含 "plugin-api-version": "2.2.0" 字段，而 Composer 1.x 解析时会直接报 Invalid lock file. Expected key "plugin-api-version" 并终止执行——这不是警告，是 fatal error。
- 团队协作必须统一 Composer 版本，不能混用；CI 流水线不能依赖系统预装的 Composer，需显式指定版本（如 GitHub Actions 中用
setup-phpaction 设置composer-version: '2.9.6'） - 升级后必须删掉旧
composer.lock再运行composer install，否则因字段缺失或校验失败中断 - 若项目中存在自定义插件，需确认其
composer-plugin-api兼容版本是否 ≥ 2.2.0
依赖解析引擎从回溯改为 SAT 求解器
Composer 2.x 解析快 2–5 倍，不是靠加缓存或调线程数，而是底层求解器彻底重写：把整个依赖约束翻译成布尔逻辑公式，用 Mumple 算法直接求解可行解空间。
- Composer 1.x 的回溯式解析在复杂项目中容易卡在某个分支反复试探；2.x 则“算版本”而非“猜版本”，结果更确定、失败更早暴露
- 模糊约束如
"psr/log": "*"或"monolog/monolog": "^1.0 || ^2.0"反而拖慢 SAT 求解器，应明确写成"psr/log": "^2.0" -
composer update --dry-run在 2.x 中更可靠，能提前暴露冲突路径，但输出受当前composer.lock影响——想评估全量变更，需先删 lock 文件再跑
并行下载默认开启但受 parallel-downloads 控制
Composer 2.x 默认启用 curl 并行下载，实际并发数由 parallel-downloads 配置项决定，默认值是 5，它影响的是同时发起的 HTTP 请求数量，而非线程或进程数。
- 查看当前值：
composer config -g parallel-downloads - 临时调高（如 CI 环境）：
composer config -g parallel-downloads 10 - 若频繁出现
curl error 7（无法连接）或超时，说明并发过高或镜像不稳定，应回退到 3–5 - 网络带宽和磁盘 IO 是瓶颈时，盲目调高反而拖慢整体速度
单包升级命令行为更严格，连带升级不可避
composer update vendor/package-name 是唯一可靠方式，仅更新指定包及其必需直系依赖，不改写 composer.json、不触发全量更新——但连带升级仍会发生，且无法关闭。
- 常见翻车点：
composer update monolog（漏掉/monolog）→ 找不到匹配项，直接全量更新 -
composer update "monolog/monolog"（加引号）→ 某些 shell 把它当字符串丢弃，等效于composer update - 连带升级是依赖图合法性的强制结果：若
monolog/monolog:^3.0要求psr/log至少^2.0，而 lock 里是1.1.4，就必须升 - 预判影响：先运行
composer show monolog/monolog查它的require列表，再加--dry-run看终端输出哪些包会被动变更
composer.lock 还原，版本切换必须靠运行时抽象、配置驱动或服务拆分来实现。 
