第2章 Composer与依赖管理

2. Composer与依赖管理：Composer安装、自动加载机制、常用包管理与版本约束

说实话，PHP 开发里最让我头疼的事，就是早期项目里那个「依赖地狱」。

我记得刚入行那会儿，要引入一个第三方库，得手动下载、解压、include，还得小心版本冲突。有一次项目上线前发现两个库用了同一个类名，直接白屏——那叫一个酸爽。

后来 Composer 出现了。嗯，这东西彻底改变了 PHP 的生态。今天咱们就好好聊聊它。

2.1 Composer 的安装与基础配置

Composer 的安装其实很简单。我个人习惯用全局安装，这样任何项目都能直接调用。

# 下载安装脚本
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"

# 验证签名（我建议每次都做这步）
php -r "if (hash_file('sha384', 'composer-setup.php') === '你的签名哈希') { echo 'Installer verified'; }"

# 安装到全局
php composer-setup.php --install-dir=/usr/local/bin --filename=composer

装完之后跑一下 composer --version，看到版本号就说明搞定了。

小技巧： 国内用户记得配镜像源。我曾经因为没配镜像，下载一个包等了十分钟。用阿里云镜像会快很多：

composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/

2.2 composer.json 与自动加载机制

每个 Composer 管理的项目，根目录下都有一个 composer.json 文件。这是项目的「身份证」。

{
    "name": "your/project",
    "description": "一个高性能API项目",
    "require": {
        "php": ">=8.0",
        "monolog/monolog": "^2.0",
        "guzzlehttp/guzzle": "^7.0"
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    }
}

这里有个关键点——自动加载。Composer 会根据 autoload 配置生成 vendor/autoload.php 文件。你只需要在入口文件里写一行：

require __DIR__ . '/vendor/autoload.php';

然后所有依赖的类就都能自动加载了。说白了，就是 Composer 帮你把 include 和 require 的脏活累活全干了。

我遇到过不少新手问：「为什么我改了命名空间，类还是加载不了？」

原因很简单——改了 composer.json 之后，你得跑一下 composer dump-autoload 重新生成加载映射。嗯，这个坑我踩过不止一次。

2.3 PSR-4 自动加载规范

Composer 默认支持 PSR-4 自动加载。这个规范说白了就是：命名空间前缀对应目录路径。

命名空间前缀	对应目录	类名示例	文件路径
App\	src/	App\Models\User	src/Models/User.php
App\Api\	src/Api/	App\Api\Controllers\OrderController	src/Api/Controllers/OrderController.php

你想想看，这种映射关系一旦建立，项目结构就非常清晰了。我现在的项目都严格遵循 PSR-4，找文件从来不用翻目录树，看命名空间就知道文件在哪。

2.4 常用包管理与版本约束

Composer 的包管理核心就两个命令：require 和 remove。

# 安装一个包
composer require monolog/monolog

# 安装指定版本
composer require monolog/monolog:2.3.0

# 移除一个包
composer remove monolog/monolog

# 更新所有包
composer update

# 只更新某个包
composer update monolog/monolog

版本约束这块，我建议你重点理解。说白了就是告诉 Composer：「我要哪个范围的版本」。

写法	含义	示例
精确版本	只允许指定版本	1.2.3
波浪号 ~	允许最后一位变化	~1.2.3 允许 1.2.x
脱字符 ^	允许不破坏向后兼容的版本	^1.2.3 允许 1.x.x
通配符 *	任意版本	1.2.*

  我的建议： 生产环境尽量用 ^ 约束。比如 ^2.0 表示 >=2.0.0 且 <3.0.0，既能拿到小版本更新，又不会因为大版本升级而炸掉。我曾经见过有人用 *，结果某天更新后接口全变了，项目直接崩了。

2.5 composer.lock 文件的重要性

这个文件很多人会忽略，但它其实特别重要。

composer.lock 记录了当前项目所有依赖的精确版本号。你想想看，团队里 A 同事装的是 2.3.1，B 同事装的是 2.3.5，如果某个 bug 只在 2.3.1 里有，那排查起来多痛苦？

所以我的习惯是：把 composer.lock 提交到 Git 仓库。这样所有人、所有环境都用同一套依赖版本。

注意： 只有 composer.lock 变了，才跑 composer install。如果只是改代码，不需要重新安装依赖。我曾经见过有人每次部署都跑 composer update，结果版本不一致导致线上 bug——嗯，那场面挺尴尬的。

2.6 生产环境优化

线上部署时，我建议加上这些参数：

composer install --no-dev --optimize-autoloader --no-interaction

解释一下：

--no-dev：不安装开发依赖（像 PHPUnit、PHPStan 这些）
--optimize-autoloader：生成优化后的自动加载映射，提升性能
--no-interaction：非交互模式，适合自动化部署

说白了，生产环境只装你真正需要的东西。少一个包，就少一个潜在的安全风险。

2.7 避坑指南

最后分享几个我踩过的坑：

不要手动修改 vendor 目录——我曾经手贱改了一个包的源码，结果下次更新全没了。要改就 fork 项目，或者用 patch 工具。
版本冲突时先看 require 的 PHP 版本——很多时候不是包冲突，而是你的 PHP 版本太低了。
用 composer why 查依赖关系——想知道某个包为什么被安装？跑 composer why monolog/monolog 就能看到是谁依赖了它。
定期跑 composer audit——检查依赖包有没有已知的安全漏洞。这个功能是 Composer 2.4 之后加的，我每次上线前都会跑一遍。

嗯，Composer 这东西，用好了能让你事半功倍。说白了它就是 PHP 生态的基石，你越了解它，开发就越顺手。