Composer是PHP的构建期依赖管理工具，仅在开发部署阶段手动触发安装，生成vendor目录和autoload.php后即退出，不参与PHP运行时执行。
Composer 不是 PHP 生命周期的一部分，它不参与 PHP 脚本的运行时执行过程，只在开发和部署阶段起作用。 它既不会被 php 解释器加载，也不会影响 php.ini、opcache 或请求生命周期（如 php_request_startup 阶段）。它的角色纯粹是“构建期工具”——类似前端的 npm install，装完就退场。
composer install 发生在什么时候？
它发生在代码部署前或本地开发初始化时，属于手动触发的离线操作：
- 不是每次 HTTP 请求都执行，也不随
index.php启动而运行 - 执行后生成
vendor/目录和vendor/autoload.php，这两个产物才进入 PHP 运行时上下文 - 若项目已存在
composer.lock，composer install会严格按该文件还原依赖，不查远程包信息；composer update才会联网解析最新兼容版本 - CI/CD 流水线中通常放在
build阶段，而非run阶段
autoload.php 怎么接入 PHP 生命周期？
它只是普通 PHP 文件，靠开发者显式引入才能生效，没有任何自动注册机制：
- 必须在入口脚本（如
index.php或public/index.php）顶部用require_once 'vendor/autoload.php';加载 - 一旦引入，它会注册一个
__autoload函数或spl_autoload_register()回调，后续类加载才触发自动查找 - 这个注册动作发生在 PHP 请求启动后的「用户代码执行阶段」，和
session_start()、error_reporting()同级，不早于php_request_startup - 如果忘记引入，会直接报
Class not found，而不是 Composer 报错
为什么改了 composer.json 却没生效？
常见于混淆「声明」和「安装」两个阶段：
立即学习“PHP免费学习笔记（深入）”；
-
composer.json只是文本声明，修改后必须运行composer install或composer update才真正写入vendor/ - 误以为
composer dump-autoload能安装新包——它只重生成自动加载映射，不下载任何代码 - 在生产环境运行
composer install但没传--no-dev，导致开发依赖（如phpunit）也被装进去，增大攻击面 - 用
git clone拉代码却漏掉composer.lock，导致composer install实际行为变成update，版本漂移
真正容易被忽略的是：Composer 的输出目录（vendor/）和自动加载逻辑（autoload.php）之间没有运行时绑定。哪怕你删掉整个 composer.phar，只要 vendor/autoload.php 还在且被正确引入，PHP 就能照常加载类——Composer 已经完成了它的全部使命。
