最直接验证方式是运行 composer --version，若输出版本号（如2.7.7）说明安装正确且PATH配置无误；否则需检查环境变量、软链接或系统时间、SSL、PHP扩展等。
运行 composer --version 看是否报错
这是最直接的验证方式。如果终端输出类似 Composer version 2.7.7，说明二进制文件已正确安装且在 $PATH 中。
常见错误现象：command not found: composer —— 表明系统找不到可执行文件，不是没装好，而是没配环境变量或没加软链接。
- Linux/macOS：检查
~/.composer/vendor/bin或你手动下载的composer.phar所在路径是否加入$PATH - Windows：确认是否将
composer.bat所在目录（如C:\ProgramData\ComposerSetup\bin）加入了系统环境变量 - 别用
php composer.phar --version代替，它绕过了 PATH 验证，不能反映真实安装状态
执行 composer init 创建最小项目
仅靠版本号不能证明 Composer 能真正工作。它依赖 PHP 环境、网络、临时目录权限等，init 是轻量但全面的“冒烟测试”。
使用场景：刚装完 Composer，或换了新机器/PHP 版本后快速确认基础链路通不通。
- 在空目录下运行
composer init，一路回车默认即可，最后会生成composer.json - 如果卡在 “Package name” 或提示
Could not load package …，大概率是网络问题（比如国内没配镜像源） - 若报
mkdir(): Permission denied，说明 Composer 尝试写缓存目录失败，检查COMPOSER_HOME指向位置是否有写权限
运行 composer install 下载一个包
这才是验证 Composer 是否“能干活”的关键一步。只看版本或初始化不等于能联网拉包、解压、生成自动加载器。
参数差异：composer install 读 composer.lock，而 composer require 会修改依赖并更新 lock 文件 —— 入门阶段优先用 install，避免意外升级。
- 先删掉刚才
init生成的composer.json，新建一个只含最简内容的文件：
{
"require": {
"monolog/monolog": "^3.0"
}
}
- 再运行
composer install。成功后应看到vendor/目录生成，且vendor/autoload.php可被 PHP 正常引入 - 如果报
SSL certificate problem，不是证书问题，大概率是系统时间不准，尤其在虚拟机或 Docker 容器里 - Windows 上遇到
proc_open(): fork failed，通常是防病毒软件拦截了进程创建，临时禁用试试
检查 composer diagnose 的输出
这个命令不是万能的，但它会暴露很多隐藏配置问题，比如镜像源失效、PHP 扩展缺失、缓存目录异常等 —— 很多人跳过这步，结果后面跑 require 时莫名其妙失败。
性能 / 兼容性影响：它不下载包，只做本地检查，耗时不到 1 秒，但能提前发现 70% 的典型环境故障点。
- 重点看最后一行是否是
OK；如果不是，上面每条提示都对应一个具体可操作项 - 如果提示
curl extension is missing，说明 PHP 编译时没启用 cURL，Debian/Ubuntu 用户需sudo apt install php-curl - 提示
The openssl extension is missing同理，但注意：PHP 8.2+ 默认要求 OpenSSL 1.1.1+，旧系统 OpenSSL 版本太低也会被诊断为“missing”
