composer install 严格按 composer.lock 还原确定性依赖，跳过版本计算；composer update 忽略 lock 文件，重跑 SAT 求解器以获取满足 composer.json 约束的最新兼容版本组合。
Composer 不是“下载器”，而是带约束求解器的依赖决策引擎——它不按你写的顺序装包，而是先算出一个全局一致的版本组合，再执行安装。
composer install 和 composer update 的本质区别在哪
两者都解析依赖，但触发条件和决策依据完全不同：
-
composer install：只看composer.lock文件。它跳过所有版本计算，直接按 lock 文件里记录的精确版本（含 commit hash、dist url、checksum）还原依赖树。没有 lock 文件？它会先生成一份，等效于跑一次composer update。 -
composer update：完全忽略composer.lock，重新读取composer.json中的版本约束（如^2.0、~1.2），调用 SAT 求解器遍历所有可能的版本组合，找出满足全部约束的最新可行解。这个过程可能耗时数秒到数分钟，尤其当存在大量冲突或网络延迟时。 - 误用风险：在 CI/CD 或生产部署中执行
composer update，会导致环境不可控——你无法保证今天装的monolog/monolog和昨天是同一个 patch 版本，哪怕约束写的是^2.0。
为什么“require A: ^1.0”和“require B: ^1.2”能共存，但“A: ^2.0”和“B: ^1.0”就报错
这不是 Composer “不够聪明”，而是版本约束在语义上天然不兼容：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
^1.0表示允许1.x.x，上限是2.0.0（不含）；^1.2同样落在1.x.x范围内，所以求解器可以选1.15.3同时满足两者。 -
^2.0要求最低2.0.0，而^1.0要求最高2.0.0（不含），二者交集为空——没有一个版本能同时满足“≥2.0.0”和“ - 常见陷阱：某些包在 v1 和 v2 之间做了 BC break（比如配置类名变更、方法签名调整），但 Composer 不管语义，只做数学交集。它报的
Your requirements could not be resolved就是这个交集为空的直白表达。
autoload 配置不是“让类能被找到”，而是告诉 Composer “哪些命名空间该映射到哪些路径”
PSR-4 映射本身不参与依赖解析，但它决定了 vendor/autoload.php 生成什么内容，进而影响运行时行为：
- 如果
composer.json里写了"psr-4": {"App\": "src/"}，Composer 就会在 autoload 阶段生成对应映射，使new AppHttpControllerHome()自动加载src/Http/Controller/Home.php。 - 但若某个第三方包没在自己的
composer.json中声明 autoload（比如只提供函数而非类），或者你漏写了"classmap": ["helpers/"]，那即使文件物理存在，require_once不显式引入，它就永远进不了自动加载流程。 - 验证方式很简单：改完 autoload 配置后，删掉
vendor/autoload.php，再跑composer dump-autoload，观察生成的文件里有没有你期望的映射项。
composer.lock 文件不是“快照”，而是“可验证的确定性契约”
它记录的不只是版本号，还包括源类型、commit reference、dist checksum、PHP 扩展要求等完整上下文：
- 当你看到 lock 文件里某包的
"source": {"type": "git", "reference": "a1b2c3..."}，说明 Composer 安装时会从 Git 克隆该 commit，而不是用 dist 包——这对调试、审计、离线部署至关重要。 - CI 环境中应始终校验
composer.lock是否与composer.json同步：运行composer install --dry-run，如果有输出差异，说明有人改了composer.json却没更新 lock，这是典型的协作隐患。 - 最易被忽略的一点：lock 文件里的
"platform": {"php": "8.1.0"}是 Composer 解析时的“虚拟平台”，它会影响求解结果。如果你本地 PHP 是 8.2，但 lock 文件锁死在 8.1，composer install仍会按 8.1 的能力去校验扩展依赖（比如是否允许ext-gd），而不是你当前环境的实际能力。
