Badger4us前阵子有个朋友在项目群里问：“Composer 安装一直失败，要不换 Code Composer Studio 试试？”我当时一愣，后来才明白他把 PHP 的依赖管理工具 Composer 和 TI 的嵌入式集成开发环境 Code Composer Studio 搞混了。这俩名字确实容易撞车，但完全不是一个世界的东西。如果你搜“Composer 安装”是想解决 PHP 项目里的依赖管理问题，那这篇文章就是给你写的；如果你要找的是那个做单片机开发的 IDE，抱歉，出门左转，咱们说的是两码事。
我最早接触 Composer 是十年前接手一个遗留 PHP 项目，当时还靠手工下载类库、手动 include，后来项目里出现十几个版本冲突的第三方包，差点把人搞崩溃。换用 Composer 之后，依赖树清晰了，版本冲突也能通过 lock 文件锁住。到今天，不管是 Laravel、Symfony 这种重量级框架，还是 ThinkPHP、Workerman 这类国内常用框架，安装和依赖管理几乎都绕不开 Composer。这篇文章不打算只讲“下一步下一步”那种安装向导，而是把 Windows、macOS、Linux 三种环境下的安装方式、安装后的镜像配置、升级策略以及我实际踩过的坑全部过一遍，争取让你看完之后能一次装好，并且知道装完之后应该做什么。
1. 安装前必须想明白的几件事：环境、版本、路径
1.1 Composer 到底是什么，它在你电脑里扮演什么角色
简单说，Composer 是 PHP 的依赖管理工具，它的地位相当于 npm 之于 Node.js、pip 之于 Python。你写代码时不需要再跑到各个开源项目主页手动下载 ZIP 包，只需要在 composer.json 里写清楚“我需要哪个包、什么版本范围”，然后执行 composer install，它就会帮你把依赖下载到 vendor 目录，并生成一个 composer.lock 文件锁定当前确切版本。
这套机制带来的最大好处是可复现。同一个项目，昨天能跑，今天换个环境跑不起来？在没用 Composer 的时代太常见了。有了 composer.lock，只要执行 composer install，它会严格按照 lock 文件里的版本拉取，绝不会因为某个库发布了新版本就把你的项目带上一个不兼容的版本。这一点在多人协作和服务器部署时价值极大。
1.2 前置条件：不是装了 PHP 就能跑
很多人在 Composer 安装这一步卡住，问题的根源往往不在 Composer 本身，而是 PHP 环境不满足要求。
Composer 是用 PHP 写的，它运行的先决条件是你机器上已经有了可用的 PHP 命令行版本。注意，这里说的是命令行版本，不是说你浏览器里能跑 PHP 网页就行。你需要打开终端，执行：
bash复制php -v
如果能看到类似 PHP 8.3.0 (cli) 这样的输出，说明 PHP 已经可用。如果提示 php 不是内部或外部命令，那说明 PHP 没有加入 PATH 环境变量，或者你压根还没安装 PHP。
接下来要看版本。Composer 2.x 要求 PHP 7.2.5 及以上版本，官方其实更推荐 PHP 7.4 以上。如果你还在用 PHP 5.x 或者 PHP 7.0、7.1 这种老古董，那只能选择 Composer 1.x，但说实话，都这个年代了，老项目如果还跑在 PHP 7.1 以下，建议先升级 PHP 再谈 Composer，否则后面一堆新包都装不上。
除了版本，还有几个 PHP 扩展是 Composer 运行所必需的：
openssl：Composer 下载包时走 HTTPS，需要它来做 TLS 通信；pdo/pdo_mysql：虽然不一定装包时立刻用到，但在安装很多数据库相关包时会触发检查；mbstring：处理多字节字符串，部分包会依赖；fileinfo：用于文件的 MIME 类型识别，某些包安装脚本会调用；zip：如果你用 Composer 的archive命令或者某些包的类型是zip分发，会用到。
检查这些扩展是否存在，可以运行：
bash复制php -m
这会列出所有已加载的模块。如果你发现缺了 openssl 或 zip，麻烦先回到 PHP 的配置里把扩展打开。Windows 下通常是去 php.ini 里取消 extension=openssl、extension=zip 前面的分号注释，然后重启终端。
1.3 版本选择：装最新还是装 LTS
Composer 的版本迭代速度不算快，但 1.x 和 2.x 之间的差异是跨越性的。2.0 版本最大的变化是底层性能大幅提升，官方自己说比 1.x 快了两倍左右。我实际体感