Composer 是现代 PHP 不可替代的基础组件,其核心在于 lock 文件锁定精确版本、autoload 按配置生成映射、require/require-dev 严格区分运行与开发依赖。
Composer 在现代 PHP 架构中不是“作用大”,而是不可替代的基础组件——没有它,Laravel、Symfony、Drupal、Magento 等主流框架根本无法启动,90% 的新项目连 vendor/autoload.php 都加载不了。
composer install 只读取 composer.lock 中锁定的精确版本,原样还原依赖树;而 composer.update 会重新解析 composer.json 中的版本约束(如 "^8.2"),尝试升级到允许范围内的最新兼容版本,并重写 composer.lock。
核心判断标准:这个包是否参与运行时逻辑?
容易踩的坑:
Composer 不是“自动”加载所有 PHP 文件,而是严格按 composer.json 的 autoload 字段生成映射规则。常见配置方式:
{
"autoload": {
"psr-4": {
"App\\":"app/",
"Tests\\":"tests/"
},
"classmap": ["src/Helpers/"],
"files": ["src/functions.php"]
}
}
当你执行 composer require some/package:2.0 报 “Your requirements could not be resolved”,别急着删 composer.lock 或强行加 @dev。
真正卡住人的从来不是 Composer 会不会用,而是搞不清「锁文件到底锁了什么」「autoload 映射到底从哪来」「为什么这个类在 CLI 下存在、Web 下却报错」——这些细节不翻源码、不看 vendor/composer/autoload_*.php 生成结果,光靠文档很难闭环。
为什么 composer install 不能代替 composer update
composer.json 里 require 和 require-dev 怎么分?
自动加载失效?先查 autoload 配置和命名空间映射
依赖冲突报错时,composer why-not 比硬改版本更可靠