composer默认非增量更新，因求解器会丢弃composer.lock并全量重校验整棵树约束；唯一可靠局部更新方式是composer update vendor/package-name。

Composer 没有真正意义上的“增量更新”机制，所谓“增量”只是靠限制命令作用范围来避免全量重算——最可靠的做法永远是 composer update vendor/package-name，其他方式都容易误触发依赖漂移。

为什么 composer update 默认不是增量的

它会扔掉 composer.lock 重跑整个依赖求解器，哪怕只改了一行 composer.json。求解器不看“哪些包变了”，而是把整棵树连同所有约束（PHP 版本、扩展、冲突规则）一起重新校验。耗时和不确定性都来自这里。

• composer update monolog/monolog 只动该包 + 它在 composer.json 中声明的 require 项（一级依赖）
• composer update --with-dependencies 会把一级依赖的依赖也纳入求解，但不会递归到三级
• composer update --with-all-dependencies 等价于全量重算，不是“更深”，而是“更慢更危险”
• 空参数运行 composer update 会忽略锁文件里所有版本锁定，哪怕 composer.lock 里写死了 "symfony/console": "6.4.0"，也会去查镜像源最新匹配版

repo.packagist 配置影响的是元数据拉取，不是更新逻辑本身

镜像源加速的是“找包信息”这一步：比如请求 https://mirrors.aliyun.com/composer/p2/laravel/framework/10.0.0.json，而不是 https://repo.packagist.org/p2/...。但它不改变 Composer 的求解行为，也不让 update 变成增量。

Discussion Composer

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

下载

• 没配 repo.packagist → 卡在几百次 provider-*.json 请求上，你以为是“更新慢”，其实是“根本没开始更新”
• 配了但镜像同步滞后 → composer update laravel/framework 找不到 10.0.0 对应的 provider 文件，报 Could not fetch packages.json 或 404，实际是镜像还没生成那个分片索引
• 切回官方源临时解决： composer config -g repo.packagist composer https://packagist.org，用完再换回来

真正能控制“只动局部”的唯一安全方式

必须显式指定包名，且不带任何扩大作用域的参数。这是唯一被 Composer 官方文档明确认可、求解器严格遵守的边界控制方式。

• composer update doctrine/dbal 不会升级 phpunit/phpunit，哪怕它被 doctrine/dbal 间接依赖
• 如果 doctrine/dbal 的 composer.json require 了 psr/cache:^2.0，而你锁文件里是 ^1.0，它也不会升 —— 因为 psr/cache 不是顶层 require，不在本次求解范围内
• 想连带升级其依赖？加 --with-dependencies，但要清楚：它只升一级依赖，不会碰 psr/cache 的子依赖 psr/log
• CI 流水线里无条件加 --with-dependencies，等于主动放弃可重现性 —— 同一 commit，不同时间跑可能得到不同 composer.lock

复杂点在于：镜像同步延迟和依赖求解边界是两套独立系统，但它们在日志里混在一起显示为“卡住”。你得先确认是 provider-laravel~10.0.json 404（镜像问题），还是 Resolving dependencies 卡住 3 分钟（求解器真在算）。前者换源，后者砍命令范围。