Composer update 变慢甚至卡住的主因是深层依赖树导致SAT求解器搜索空间爆炸；收紧版本约束、禁用冗余插件、配置config.platform、合理使用replace/provide及清理require-dev可显著提速。

Composer 默认会把所有依赖尽可能“拉平”到 vendor/ 顶层，不是为了省空间，而是为了解决菱形依赖冲突——但扁平化本身不会自动缩小依赖树规模；树庞大，往往是因为约束太松、版本没收敛、或引入了过度复杂的包。

为什么 composer update 越来越慢，甚至卡住？

深层依赖树会让 SAT 求解器搜索空间爆炸。Composer 不是简单地“一层层装”，它要找出满足所有 require 约束的全局一致版本组合。路径越多、版本范围越宽（比如用 ^1.0 而不是 ^1.3.0），可行解就越多，求解就越耗时。

• 检查 composer.json 里有没有泛泛而谈的版本约束，比如 "monolog/monolog": "^1.0" —— 改成 "^1.30.0" 可显著收窄搜索范围
• 运行 composer prohibits --tree monolog/monolog 看哪些包在拖后腿，尤其是 dev-only 包或私有 repo 的宽松约束
• CI 中避免无参数 composer update：明确指定要更新的包，如 composer update guzzlehttp/guzzle --with-dependencies
• 禁用非必要插件：某些插件（如 hirak/prestissimo）在新版 Composer 中已失效，反而干扰解析

config.platform 怎么帮依赖解析提速？

Composer 在解析前会探测当前 PHP 版本、扩展是否可用，这个过程在容器或 CI 中可能反复失败或超时。用 config.platform 硬编码环境信息，能跳过探测，让求解器直接基于你声明的平台做约束裁剪。

Discussion Composer

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

下载

• 在 composer.json 里加：

  "config": {
    "platform": {
      "php": "8.2.15",
      "ext-zip": "1.21.0",
      "ext-pdo_mysql": "8.2.15"
    }
  }

• 不要写 "ext-foobar": "*" —— 这会让 Composer 认为你接受任意版本，反而扩大搜索空间
• PHP 主版本必须严格匹配：写 "php": "8.2" 会导致它仍尝试兼容 8.2.0 到 8.2.99，应锁定小版本（如 "8.2.15"）以减少变体

什么时候该用 replace 或 provide？

当多个包提供相同能力（比如都实现 PSR-3 Logger），但版本不一，Composer 就会为每个路径装一份——这不是 bug，是设计使然。用 replace 可显式告诉 Composer：“这个包我已有替代品，别装了”。

• 例如你用 psr/log 3.0，但某旧包只写 "psr/log": "^1.0"，可在根 composer.json 加：

  "replace": {
    "psr/log": "self.version"
  }

  （前提是你的项目已含兼容实现）
• provide 更适合 SDK 类包：比如你发布一个封装了 guzzlehttp/guzzle 和 monolog/monolog 的内部 HTTP 客户端，可声明 "provide": {"guzzlehttp/guzzle": "^7.0", "monolog/monolog": "^2.0"}，下游项目再 require 同样功能时就不会重复安装
• 注意：replace 不会自动加载被替换的包，你得自己确保类存在且可 autoload

依赖树庞大最常被忽略的点，不是怎么“压平”，而是没意识到 require-dev 里的包也会参与全局约束求解——哪怕它们只在本地跑测试。删掉不用的 dev 工具，比调任何配置都管用。