Composer install卡在“Resolving dependencies”是本地CPU运行SAT求解器暴力遍历版本组合所致，非网络问题；常见原因包括dev稳定性配置、间接依赖冲突、删composer.lock退化为update、xdebug干扰等。

因为它不是“装包工具”，而是用数学求解器决定哪些版本能共存、哪些类该从哪加载——不理解这点，所有报错都只能靠猜。

Composer install 卡在 “Resolving dependencies” 是什么问题

这不是网络慢，是本地 CPU 正在用 SAT 求解器暴力遍历所有可能的版本组合。常见触发条件包括：

• minimum-stability 设为 "dev"，让求解器主动纳入大量不稳定分支，搜索空间爆炸
• 间接依赖冲突：比如 A 包 require guzzlehttp/guzzle:^7.0，B 包 require guzzlehttp/guzzle:^8.0，而你又锁死了 monolog/monolog:2.9.0，导致回溯剪枝反复失败
• 删了 composer.lock 文件，install 就退化成 update，每次都要重算
• 开了 xdebug（会让求解慢 5–10 倍），或启用了干扰插件（如某些 IDE 集成）

为什么必须保留 composer.lock 并提交到 Git

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 完全跳过求解，只按 lock 文件逐条下载安装，构建结果 100% 可复现
• 删掉它或手动改 composer.json 后再 install，就等于强制重跑 SAT 求解——CI 构建可能通过，你本地却报 Your requirements could not be resolved
• packages-dev 区块独立存在，开发依赖不参与生产求解，但会影响你本地 install 的结果（比如是否装 phpunit）

require 中写 "*"@dev 和 "^2.0" 的本质区别

这是本地开发与远程发布的分水岭：

• 写 "acme/utils": "^2.0"：Composer 会忽略本地 repositories 配置，直接去 Packagist 查找已发布的 2.x 版本
• 写 "acme/utils": "*@dev" 或 "acme/utils": "@dev"：明确告诉求解器“无条件取本地最新”，不走远程匹配逻辑
• 包名大小写、连字符、斜杠方向全部敏感："acme/utils" ≠ "Acme/Utils"，写错一个字符，就会静默 fallback 到 Packagist 加载旧代码
• 子包自己的 composer.json 里写再多 repositories 都无效——Composer 只读根目录下的 composer.json 中的 repositories 字段

autoload 不是拼路径，而是建映射表

vendor/autoload.php 是 Composer 构建的加载策略中心，背后有三类机制并存：

• PSR-4：前缀 → 目录映射，如 "Monolog\": "src/" → 加载 MonologLogger 时自动找 src/Logger.php
• classmap：扫描后生成的全量类名 → 文件路径数组，适合无命名空间的老库
• files：直接 require 某些全局函数文件（如 src/functions.php）
• 运行时不会实时扫描文件系统；加了 --classmap-authoritative 后，“找不到就真没有”，不 fallback，性能更高但要求 classmap 必须完整

最常被忽略的一点：Composer 的核心动作从来不是“下载”，而是“求解”。所有看似随机的报错、卡顿、行为不一致，几乎都源于对这个数学过程的误判或绕过——比如删 lock、乱配 stability、信错子包配置。理解这一点，才能真正掌控依赖边界。