17370845950

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"

容易踩的坑：

• 把测试工具误写进 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 是首选，但要求目录结构与命名空间完全一致：类 App\Http\Controllers\HomeController 必须在 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 生成结果，光靠文档很难闭环。