Composer运行始于CLI命令解析，通过Symfony Console加载对应命令类；随后读取composer.json与lock文件，利用SAT求解器解析依赖关系；确定版本后从dist或source下载包并校验，安装至vendor目录；接着生成autoload映射文件，并执行scripts中定义的钩子脚本如post-install-cmd，完成自动化任务。整个流程为：命令解析→配置加载→依赖求解→包下载→文件写入→自动加载生成→脚本执行，各环节环环相扣，确保依赖管理高效可靠。
当你在终端输入 composer install 或 composer require 时，Composer 并不是简单地下载几个文件就结束。它背后有一条完整的执行链路，从命令解析到依赖解析、脚本执行，再到文件写入，每一步都经过精心设计。下面带你一步步拆解 Composer 的运行原理。
命令解析：从 CLI 入口开始
Composer 的入口文件是 bin/composer，这是一个 PHP 脚本。当你运行 composer 命令时，系统会调用这个脚本，启动 PHP 解释器。
该脚本会引入 Composer 的核心应用类，并初始化一个命令行应用程序（基于 Symfony Console 组件）。然后根据你输入的子命令（如 install、update、require）匹配对应的 Command 类。
- 用户输入命令 → Shell 调用 composer 可执行文件
- PHP 启动并加载 Composer 自动加载器（autoload.php）
- Symfony Console 解析命令参数和选项
- 找到对应命令类（如 InstallCommand）并执行 handle()
配置加载与依赖分析
命令执行后，Composer 会读取当前目录下的 composer.json 文件，这是项目依赖的声明文件。它还会加载 composer.lock（如果存在）以及全局配置（如仓库镜像、认证信息）。
以 composer install 为例：
- 如果没有 lock 文件，Composer 会根据 composer.json 中的版本约束，向 Packagist 发起请求获取可用包列表
- 使用 SAT 求解器（Solver for Satisfiability Modulo Theories）计算出一组满足所有依赖关系的包版本组合
- 结果写入 vendor/ 目录，并生成或更新 composer.lock
而 composer update 则会忽略 lock 文件，重新进行依赖求解，可能导致版本升级。
包的下载与安装流程
确定了要安装的包及其版本后，Composer 开始下载这些包。它支持多种源类型：dist（压缩包）、source（Git 仓库）等。
- 对于 dist 包，Composer 会从指定 URL 下载 ZIP 或 TAR 归档
- 校验 checksum 确保完整性
- 解压到临时目录，再移动到 vendor/ 下对应位置
- 同时记录安装信息到 installed.json（位于 vendor/composer/）
如果是开发依赖或 source 类型包，Composer 还会执行 Git 克隆，并检出指定分支或标签。
自动加载生成与脚本执行
所有包安装完成后，Composer 会重建自动加载映射。它扫描 vendor/ 中所有包的 autoload 配置（PSR-4、PSR-0、classmap、files），生成 vendor/autoload.php 和一系列映射文件。
紧接着，Composer 触发定义在 scripts 中的事件钩子。例如：
- post-install-cmd：常用于清除缓存、生成配置
- post-update-cmd：提示用户检查变更
- pre-autoload-dump：在生成 autoloader 前执行某些操作
这些脚本可以是 PHP 回调函数，也可以是 shell 命令，极大增强了扩展能力。
基本上就这些。Composer 的整个执行过程看似复杂，实则模块清晰：命令驱动 → 配置解析 → 依赖求解 → 包获取 → 文件写入 → 自动加载生成 → 脚本回调。理解这条链路，有助于排查问题，比如 lock 文件为何重要、autoload 为何需要 dump、scripts 如何生效等。不复杂但容易忽略细节。
