composer install变慢是因为退化为隐式update：当composer.lock丢失或损坏、composer.json被修改未同步lock、缓存缺失导致fallback超时，它会重跑依赖解析；判断依据是输出“resolving dependencies”。
不是错觉，composer install 确实可能比 composer update 更慢——这通常意味着它根本没走“快速安装路径”，而是退化成了隐式 update。
composer install 什么时候会变慢到像 update？
它本该只读 composer.lock、解压 vendor、跳过依赖解析。但以下情况会让它强行重跑整套求解流程：
-
composer.lock丢失或损坏，Composer 只能回退到解析composer.json -
composer.json被修改过（比如改了 PHP 版本约束、增删了 require），但没运行composer update --lock或删 lock 后重生成 - 本地缓存里缺某个包的 dist 文件，且镜像源 fallback 到 packagist.org 后又超时，触发反复重试和元数据回溯
如何判断 install 是否真的在“假装快”？
看终端输出第一行是不是 Resolving dependencies。如果是，说明它正在做 update 才做的事——你手里的 composer.lock 已失效或不匹配。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer install --dry-run：不装包，只校验一致性。如果报错或提示要更新某些包，就证实 lock 文件和 json 不同步 - 对比
composer.json的platform配置和当前 PHP 版本：php -v与composer config platform.php不一致时，Composer 会重新求解兼容版本 - 检查
composer.lock文件最后修改时间是否早于composer.json修改时间
为什么换镜像、关 Xdebug 还是慢？
网络和 PHP 配置只是表层原因。真正卡住的点往往在依赖结构本身：
-
composer.lock文件过大（>5MB）：含大量未清理的require-dev元数据，PHP 解析 JSON + 构建依赖图耗 CPU - 启用了已废弃插件（如
fxp/composer-asset-plugin），会在 install 阶段额外请求 Bower/NPM 元数据 - vendor 目录存在但部分包损坏，Composer 默认开启完整性校验（尤其用了
--prefer-dist），会逐个验证 hash
最常被忽略的是 lock 文件的“隐性腐化”：它不报错，但包含已下线包的引用、重复字段、或 dev 依赖残留。这种情况下，哪怕所有配置都正确，install 也会在后台默默做大量无用计算。
