composer update卡在“resolving dependencies”是本地穷举版本组合导致的sat求解瓶颈，非网络问题；应收紧约束、禁用xdebug、清理缓存、换镜像、设minimum-stability为stable，并用--dry-run -vvv和why-not定位冲突。
composer update卡在“Resolving dependencies”怎么办
这不是网络问题，是 Composer 在本地穷举版本组合，尤其当 composer.json 里有宽泛约束（如 "^1.0 || ^2.0"）、minimum-stability 设为 dev，或依赖树深度超过 5 层时，耗时会从秒级跳到数分钟。
立刻验证是否真被卡住：composer update --dry-run -vvv。如果也卡，说明是解析瓶颈；如果不卡，大概率是某个插件（比如残留的 hirak/prestissimo）干扰了新版 Composer 的并行逻辑。
- 删掉
minimum-stability字段，或显式设为"stable"，避免自动拉取dev-分支触发额外校验 - 运行
composer why-not vendor/package:version快速定位冲突包，比干等强得多 - 临时禁用 xdebug：
php -d zend_extension= -d xdebug.mode=off /usr/bin/composer update，它会让解析慢 5–10 倍 - 确认没误加
--with-all-dependencies或--ignore-platform-reqs，它们会绕过缓存、强制重算整棵树
全局配置里哪些项真正影响 update 速度
很多用户只换镜像源就以为结束了，但实际生效的配置优先级是：命令行参数 > 当前项目 composer.json > 全局 config.json。项目根目录下若有自定义 repositories 指向已下线私有源，Composer 会逐个尝试超时后才 fallback，拖慢整条链路。
执行 composer config --list --global 和 composer config --list 对比，看真实生效的源和设置。
- 强制指定缓存路径到 SSD：
composer config -g cache-dir /ssd/.composer/cache，别让它默认写进加密卷或机械盘 - 启用
discard-changes true避免 CI 脚本中因交互提示卡住：composer config -g discard-changes true - 禁用废弃插件：
composer global remove hirak/prestissimo，它在 Composer 2.x 中已失效，还可能引发静默降级 - 确认
repos.packagist.org.url指向的是https://mirrors.aliyun.com/composer/，不是已停服的旧地址
为什么用了国内镜像还是慢
换源只是第一步，若仍慢，大概率是缓存未清理或配置被覆盖。Composer 会优先读取项目级 composer.json 中的 repositories，哪怕全局已设阿里云源，只要项目里写了失效的私有源，就会先连那个源超时再 fallback。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
临时绕过所有自定义源验证网络是否真通：composer update --no-plugins --repository=https://packagist.org。如果快了，说明项目级配置有问题。
- 换源后必须清缓存：
composer clear-cache，否则旧元数据仍走海外源 - 检查项目
composer.json是否含"type": "package"或自定义 VCS 源，这类源不走镜像，且无 CDN 加速 - 某些企业代理会干扰 TLS 握手，导致并发变负优化，可临时关并行：
composer config -g disable-tls false - 确认没在 Docker 容器里跑，且挂载的
/root/.composer/cache目录权限可写，否则缓存失效
如何让 update 只改一个包而不重算全量
默认 composer update 会丢弃整个 composer.lock，重新解析全部依赖。你真正需要的往往只是“精准更新”，不是重建锁文件。
只更新单个包：composer update vendor/package（不带版本号），Composer 会复用 composer.lock 中其他包的已知兼容版本，跳过大部分求解过程。
- 加
--with-dependencies仅当确实要连带升级其子依赖；多数情况不加更稳更快 - 生产环境部署禁止用
update，一律用install --no-interaction --no-scripts，靠 lock 文件保证一致性 - CI 中避免无条件跑
composer update，应先composer validate --strict确认 lock 合法，再 install - 如果必须更新多个包，用空格分隔：
composer update vendor/a vendor/b，别用逗号或引号
最常被忽略的点是：composer.lock 是否提交到了 Git。没它，install 就退化成 update；而一旦有了它，update 就不该在生产流程中出现。
