Windows 11 安装 Composer 的完整流程，以及环境变量如何设置

对于 PHP 开发者来说，Composer 几乎已经是现代 PHP 项目的基础工具。Laravel、Symfony，以及大量第三方 PHP 库，都依赖 Composer 管理软件包和版本关系。它解决的不是“把几个 PHP 文件下载下来”这么简单的问题，而是负责解析项目依赖、安装指定版本的软件包，并生成自动加载器。

在 Windows 11 上安装 Composer 本身并不复杂。真正容易出问题的地方，通常不是 Composer，而是 PHP 没有正确安装，或者 PHP 没有加入 Windows 的 PATH 环境变量。

因此，安装 Composer 之前，第一件事不是下载 Composer，而是先确认 PHP 本身能够在命令行运行。

打开 Windows Terminal、PowerShell 或命令提示符，输入：

php -v

如果能够看到 PHP 版本号，说明当前终端已经能够找到 PHP。如果出现“php 不是内部或外部命令，也不是可运行的程序”等提示，就应该先解决 PHP 的安装和 PATH 配置问题。

这一点非常重要，因为 Composer 本身运行在 PHP 环境之上。Composer 官方 Windows 安装程序会检查 PHP 环境，并使用现有 PHP 来运行 Composer。

确认 PHP 可以运行之后，再安装 Composer。

目前 Windows 用户最推荐的方式，是直接使用 Composer 官方提供的 Composer-Setup.exe 安装程序，而不是自己下载一个 .phar 文件再制作批处理文件。Composer 官方文档明确把 Windows Installer 列为最简单的安装方式。安装程序会安装 Composer，并设置 PATH，使用户可以直接在任意命令行目录执行 composer。

下载时应该使用 Composer 官方网站：

Composer 官方下载页面

下载页面会提供 Windows Installer。安装文件通常是 Composer-Setup.exe。

双击运行以后，安装程序会要求选择 PHP 可执行文件。如果电脑已经正确安装 PHP，安装程序通常可以检测到 PHP 的路径。例如：

C:\php\php.exe

或者：

C:\xampp\php\php.exe

具体路径取决于你的 PHP 安装方式。

这里有一个非常关键的概念：Composer 的 PATH 和 PHP 的 PATH 是两个相关但不同的问题。

如果命令行能够执行：

php -v

说明 PHP 已经在 PATH 中。

如果安装 Composer 后能够执行：

composer -V

说明 Composer 也已经在 PATH 中。

两个命令都能正常运行，PHP 的命令行环境基本就建立好了。

Composer 安装程序会自动处理 Composer 的 PATH，因此普通 Windows 用户通常没有必要手工进入系统变量，把 C:\Program Files\Composer 之类的路径添加进去。官方 Windows 安装程序的目的之一就是减少这种手工配置。

如果你确实需要手工配置 PATH，例如使用 Composer 的手动安装方式，那么才需要进入 Windows 11 的环境变量设置。

可以在 Windows 搜索框中输入：

环境变量

选择“编辑系统环境变量”，然后进入“环境变量”。

Windows 的环境变量分成“用户变量”和“系统变量”。

用户变量只影响当前 Windows 用户；系统变量则可以供系统中的用户使用。对于个人开发电脑，没有必要为了 Composer 强行修改系统变量。只要当前用户能够正常使用 Composer，配置用户 PATH 通常已经足够。

在 PATH 中添加的是目录，而不是某个具体文件。

例如，如果手动安装的 Composer 位于：

C:\bin

那么 PATH 应该添加：

C:\bin

而不是：

C:\bin\composer.phar

Composer 官方的手动安装方法也是将 composer.phar 放在 PATH 中的目录，然后创建一个 composer.bat，让 Windows 可以通过 composer 命令调用它。

Windows 的路径中出现空格本身并不是错误。

例如：

C:\Program Files\PHP

完全可以作为合法路径。Windows 命令行和 PHP 程序都能够处理包含空格的路径。需要引号的是某些命令中的路径参数，而不是因为 Composer 本身无法处理 Program Files。

因此，没有必要为了避免空格而强行把所有软件都安装到：

C:\Composer

或者：

C:\PHP

安装目录应该根据实际开发环境决定。

Composer 安装完成以后，必须关闭原来的终端窗口，再重新打开一个 PowerShell 或 CMD。

这是很多初学者容易忽略的一步。

因为 PATH 通常是在终端启动时读取的。如果 Composer 安装程序刚刚修改了 PATH，而你继续使用安装之前已经打开的 CMD，那么这个窗口可能仍然不知道新的 PATH 内容。Composer 官方文档也特别提醒，安装后应该关闭当前终端，然后打开新的终端进行测试。

重新打开终端以后，可以依次执行：

php -v

然后：

composer -V

如果两个命令都显示版本号，基本就说明环境配置成功。

还可以进一步执行：

composer diagnose

Composer 官方建议遇到安装或运行问题时使用这个命令检查常见配置问题。

如果 php -v 正常，而 composer -V 提示找不到命令，那么重点检查 Composer 是否已经加入 PATH。

Windows 下还可以使用：

where php

查看系统实际调用的是哪个 PHP。

同样可以执行：

where composer

查看系统实际找到的是哪个 Composer。

这两个命令非常有用。特别是在电脑上安装过多个 PHP 版本、XAMPP、WAMP 或其他 PHP 开发环境时，php -v 显示的版本不一定就是你以为正在使用的那个 PHP。

例如电脑中可能同时存在：

C:\php\php.exe

以及：

C:\xampp\php\php.exe

如果 PATH 中两个路径同时存在，那么 Windows 会按照 PATH 的顺序寻找程序。于是你看到的 PHP 版本可能来自另一个目录。

Composer 使用的是命令行环境中的 PHP，因此 PHP 版本选错，也可能造成 Composer 安装软件包时出现平台要求错误。

例如某个项目要求：

php: ^8.2

而你的命令行实际上运行的是 PHP 8.1，那么 Composer 就可能拒绝安装相关依赖。

这并不意味着 Composer 出了问题，而是项目要求与当前 PHP 环境不匹配。

Composer 的另一个重要概念，是项目依赖并不应该通过“全局安装”来解决。

一个标准 PHP 项目通常会拥有：

composer.json

这个文件描述项目需要哪些依赖。

执行：

composer install

Composer 会读取项目中的 composer.json。如果同时存在：

composer.lock

Composer 会按照锁定的版本安装依赖，并把第三方代码放进通常名为：

vendor

的目录。Composer 官方文档也建议，在已有 composer.lock 的项目中使用 composer install，以保持不同开发环境之间的依赖版本一致。

例如一个 PHP 项目可能出现这样的结构：

my-project/
composer.json
composer.lock
vendor/
public/
src/

安装完成以后，PHP 项目通常会使用 Composer 自动生成的：

vendor/autoload.php

然后在 PHP 程序中：

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

这样第三方 PHP 类库就可以通过 Composer 的自动加载机制使用。

至于 Redis，也需要纠正一个常见误解。

不要把：

composer global require php/pecl/redis

当成安装 PHP Redis 扩展的标准方法。

PHP 的 Redis 扩展属于 PHP 扩展层面的组件，它和普通 PHP 用户空间软件包不是一回事。Composer 管理的是 PHP 项目依赖，而 PHP 扩展通常需要通过 PECL、操作系统软件包、对应的 Windows 扩展 DLL 或其他与你的 PHP 构建版本匹配的方式安装。

如果项目要求：

ext-redis

Composer 检查的是当前 PHP 是否已经提供 Redis 扩展。

这和安装一个普通 Composer 包完全是两个层面。

同样，如果 Composer 报：

ext-mbstring is missing

也不能简单通过 Composer 安装一个普通软件包来解决。应该检查当前 PHP 的扩展配置，例如 php.ini 和对应的扩展 DLL。

另外，也没有必要为了安装 Composer 而关闭 Windows Defender。

正常情况下应该从 Composer 官方网站下载安装程序。如果 Windows 安全功能对下载文件提出警告，应先确认文件来源和数字签名，而不是把整个安全软件关闭。

Composer 本身也涉及软件包、插件和脚本执行，因此开发环境的安全问题不能完全忽略。Composer 官方明确提醒，Composer 插件和脚本可以以运行 Composer 的用户权限执行代码，因此不应该随意安装来源不明的依赖。

Composer 安装完成后也不需要创建所谓“进入命令行的快捷方式”。

Composer 本身就是一个命令行工具。只要 PATH 配置正确，在项目目录中打开终端即可运行：

composer install

或者：

composer update

也可以：

composer require monolog/monolog

这些命令应该在具体 PHP 项目的目录中执行，而不是为了方便专门建立一个 Composer 桌面快捷方式。

Composer 还提供：

composer self-update

用于更新 Composer 自身。Composer 官方下载页面显示，目前 Composer 2.10.x 是当前稳定版本线，同时 Composer 2.2 LTS 仍有单独的维护周期。实际安装时应根据当前 PHP 版本和项目兼容要求选择合适版本，而不是机械地追求某一个固定版本号。

如果 Composer 出现异常，可以按照一个比较清晰的顺序排查。

先执行：

php -v

确认 PHP 正常。

然后：

where php

确认使用的是哪个 PHP。

再执行：

composer -V

确认 Composer 是否能够被找到。

然后：

where composer

确认实际调用的是哪个 Composer。

最后：

composer diagnose

检查 Composer 环境中的常见问题。

如果这些步骤都正常，而项目安装依赖仍然失败，再查看 Composer 给出的具体错误。尤其需要关注 PHP 版本、PHP 扩展、SSL/TLS、网络连接以及 composer.json 中的版本约束。

对于 Windows 11 的 PHP 开发环境来说，最简单可靠的思路其实并不复杂：先让 php -v 正常，再使用 Composer 官方的 Composer-Setup.exe 安装 Composer，让安装程序处理 PATH；重新打开终端后，用 composer -V 和 composer diagnose 验证环境。只有在使用手动安装方式时，才需要自己处理 composer.phar、composer.bat 和 PATH。

Composer 真正解决的问题，也不是“安装一个 PHP 工具”这么简单。它建立的是一套可重复的 PHP 依赖管理机制。项目通过 composer.json 声明需要什么，通过 composer.lock 固定实际使用的版本，再通过 vendor 和自动加载机制把第三方代码纳入项目。把 PHP、Composer、PHP 扩展和项目依赖这几个层次区分清楚，Windows 11 上的 PHP 开发环境就不会因为一个 PATH 或版本问题反复折腾。