composer 是现代 php 不可替代的基础组件，其核心在于 lock 文件锁定精确版本、autoload 按配置生成映射、require/require-dev 严格区分运行与开发依赖。
Composer 在现代 PHP 架构中不是“作用大”，而是不可替代的基础组件——没有它，Laravel、Symfony、Drupal、Magento 等主流框架根本无法启动，90% 的新项目连 vendor/autoload.php 都加载不了。
为什么 composer install 不能代替 composer update
composer install 只读取 composer.lock 中锁定的精确版本，原样还原依赖树；而 composer.update 会重新解析 composer.json 中的版本约束（如 "^8.2"），尝试升级到允许范围内的最新兼容版本，并重写 composer.lock。
- 常见错误现象：本地
composer install正常，CI/CD 流水线却报类未找到 —— 很可能因为没提交composer.lock，导致不同环境解析出不同版本，PSR-4 自动加载路径错乱 - 生产环境必须用
composer install（不带--no-dev也要加） - 开发中更新单个包推荐：
composer update monolog/monolog，避免全量更新引发隐性冲突 -
composer update后务必跑一遍测试 —— 即使小版本升级（如7.4.2 → 7.4.3）也可能改变异常抛出逻辑或返回类型
composer.json 里 require 和 require-dev 怎么分？
核心判断标准：这个包是否参与运行时逻辑？
-
require：运行必需，比如"guzzlehttp/guzzle": "^7.5"（HTTP 客户端）、"doctrine/dbal": "^3.7"（数据库抽象层） -
require-dev：仅开发/测试阶段需要，比如"phpunit/phpunit": "^10.5"、"phpstan/phpstan": "^1.10"、"laravel/pint"
容易踩的坑：
立即学习“PHP免费学习笔记（深入）”；
- 把测试工具误写进
require→ 生产部署多装几十 MB 无用包，还可能引入安全风险 - 把日志驱动（如
monolog/monolog）只放require-dev→ 上线后Log::error()直接报Class not found -
composer install --no-dev在生产环境是强制项，但 CI 脚本里漏掉它，会导致测试命令找不到 PHPUnit
自动加载失效？先查 autoload 配置和命名空间映射
Composer 不是“自动”加载所有 PHP 文件，而是严格按 composer.json 的 autoload 字段生成映射规则。常见配置方式：
{
"autoload": {
"psr-4": {
"App\": "app/",
"Tests\": "tests/"
},
"classmap": ["src/Helpers/"],
"files": ["src/functions.php"]
}
}
- PSR-4 是首选，但要求目录结构与命名空间完全一致：类
AppHttpControllersHomeController必须在app/Http/Controllers/HomeController.php -
classmap适合老式函数库或无命名空间的类，执行composer dump-autoload才会扫描并生成映射 -
files里的文件会在每次请求时被无条件include_once，慎用（比如全局 helper 函数可放这里，但别塞大文件） - 修改 autoload 后必须运行：
composer dump-autoload -o（-o表示优化，生成静态映射提升性能）
依赖冲突报错时，composer why-not 比硬改版本更可靠
当你执行 composer require some/package:2.0 报 “Your requirements could not be resolved”，别急着删 composer.lock 或强行加 @dev。
- 先用：
composer why-not some/package:2.0，它会明确告诉你哪个已装包（比如laravel/framework v10.32.1）要求symfony/console ^6.2，而some/package:2.0要求^7.0，直接冲突 - 再查该包是否有 LTS 版本适配当前生态，例如改用
some/package:^1.8 - 如果必须上新版，可配合
composer prohibits查清谁在阻止安装 - 切忌在团队项目中随意运行
composer update—— 一个^符号背后可能是主版本跃迁，破坏向后兼容性
真正卡住人的从来不是 Composer 会不会用，而是搞不清「锁文件到底锁了什么」「autoload 映射到底从哪来」「为什么这个类在 CLI 下存在、Web 下却报错」——这些细节不翻源码、不看 vendor/composer/autoload_*.php 生成结果，光靠文档很难闭环。
