composer diagnose 是 Composer 自带的诊断命令，可一步检查 PHP 版本、扩展启用（如 openssl/zlib）、网络连通性、vendor 权限、composer.json 合法性等 12 项关键项，失败时标红并提示修复方向，暴露 90% 部署卡点。
Composer环境检测不是靠猜，而是用 composer diagnose 一步到位——它会检查 PHP 版本、扩展启用状态、网络连通性、vendor/ 权限、composer.json 格式合法性等共 12 项关键项，失败时直接标红并提示修复方向。
运行 composer diagnose 看哪些项目不通过
这条命令是 Composer 自带的诊断入口，不依赖外部工具，也不需要改配置。它默认只检查基础环境，但足够暴露 90% 的部署卡点：
-
PHP version：是否低于 Composer 要求（当前最低 PHP 7.2.5，但若用 PHP 8.3+ 的新包，可能报ext-json版本不匹配） -
openssl extension：缺失会导致https://packagist.org连接失败，错误常被掩盖成 “Could not parse version constraint” -
zlib extension：没启用时，composer install会卡在解压阶段，-vvv日志里出现zlib_decode(): data error -
HTTP proxy：如果公司用了代理但没配http-proxy或no-proxy，这里会明确提示 “Unable to reach github.com” -
vendor/ permissions：尤其在 Docker 或 CI 环境中，vendor/目录属主不对（比如 root 写、www-data 读），会导致 autoload 失败但报错很模糊
加 --profile 和 -vvv 不是叠加，是分阶段用
composer diagnose 只告诉你“哪块坏了”，不告诉你“怎么坏的”。真要定位根因，得按场景切换参数：
- 怀疑安装过程慢？用
composer install --profile：看耗时大户是Resolving dependencies（SAT 卡死）、Generating autoload files（PSR-4 映射爆炸），还是post-install-cmd（某个脚本在扫描整个config/目录） - 命令直接报错或卡死？必须上
composer update -vvv：只有它会打印 cURL 原始响应体、SAT 求解器每一步排除了哪个版本、插件堆栈，以及ext-foobar在config.platform里写了但实际没装的真实提示 -
-vvv没输出？先查三件事：composer config verbose是否被设为false；config.platform里有没有写错扩展名；是否被 Xdebug 干扰（加COMPOSER_DISABLE_XDEBUG=1再试）
脚本里别硬编码 php composer.phar，用 which composer 动态找
自动化部署脚本里常见低级错误：写死 php /path/to/composer.phar install，结果在不同服务器路径不一致，或者系统 PATH 里已有全局 composer 命令却绕开不用。
- 正确做法是先探测：
if ! command -v composer &> /dev/null; then echo "composer not found"; exit 1; fi - 再执行：
composer install --no-dev --optimize-autoloader，而不是php composer.phar install - 如果必须用 PHAR（如某些容器镜像没配 PATH），也该用
php "$(dirname "$0")/composer.phar"相对路径，避免绝对路径失效 - CI 环境中还要注意：
CI=true会被某些包识别并跳过交互式提示，但若脚本里用了read -p这类阻塞操作，就得提前判断[ -t 0 ]
真正难排查的永远不是“命令跑不了”，而是“命令跑完了但结果不对”——比如 diagnose 全绿，install 也成功，但 require 'vendor/autoload.php' 启动慢 2 秒。这时候得切到 PHP 层，用 strace -e trace=openat,stat php -r "require 'vendor/autoload.php';" 看它到底打开了哪些文件，而不是继续在 Composer 日志里打转。
