composer diagnose 是首选检查方式，因为它实打实探测PHP CLI、必需扩展、临时目录、CA证书、缓存路径及远程仓库连通性等硬性依赖，比逐个排查更可靠。
直接运行 composer diagnose，它会一次性暴露所有环境问题，比逐个查 PHP 版本、扩展、网络更可靠。
为什么 composer diagnose 是首选检查方式
它不是只看配置文件，而是实打实地探测：PHP CLI 是否可用、openssl/mbstring/zlib/phar 扩展是否加载、临时目录是否可写、CA 证书是否有效、缓存路径是否合法、以及能否连通远程仓库（默认是 packagist.org）。这些全是 Composer 运行的硬性依赖。
常见误判点：composer diagnose 把「无法访问 packagist.org」标为 ERROR，但如果你已配阿里云镜像（repo.packagist 指向 https://mirrors.aliyun.com/composer/），这个 ERROR 其实可以忽略——它只是检测默认源，不代表你不能用。
加 -v 参数能看到每一步检测详情和失败原因，比如：
Checking platform settings: OK Checking git settings: OK Checking http connectivity to packagist: WARNING [Composer\Downloader\TransportException] The "https://repo.packagist.org/packages.json" file could not be downloaded (HTTP/2 404)
这时别急着重装，先跑 composer config -g repo.packagist 确认输出是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
composer show --platform 查 PHP 运行时真实能力
当你遇到 ext-gd not found 或 ext-xml not loaded 类报错，composer show --platform 比 php -m 更准——它只列 Composer 实际校验过的扩展和组件版本，且不读任何配置，纯看当前 CLI 环境加载了什么。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
关键点：
- 如果
composer.json里写了"ext-gd": "*"，但这里没显示gd，安装必然中断 - 它不显示未启用的扩展（比如 php.ini 里注释掉的
extension=gd），所以得先确保php -m | grep gd有输出 - 输出里还会包含
libxml、iconv、json等底层组件版本，某些旧版 libxml 会导致依赖解析异常
PATH 和 PHP CLI 不通，composer diagnose 根本跑不起来
如果终端敲 composer diagnose 提示 command not found 或 不是内部或外部命令，说明环境链在最底层就断了。必须按顺序确认：
- 运行
php -v，有正常输出才算 PHP CLI 就绪；若报错，Composer 启动不了 - Windows 用户检查 PATH 是否加了
C:\ProgramData\ComposerSetup\bin（不是php.exe路径），且该目录下存在composer.bat - Linux/macOS 用户检查
which composer和ls -l $(which composer)，确保文件存在且有+x权限（sudo chmod +x /usr/local/bin/composer） - 宝塔等面板环境注意：终端默认 PHP 可能不是面板里用的那个，需手动软链，例如
ln -sf /www/server/php/82/bin/php /usr/local/bin/php
这些前置条件不满足，composer diagnose 压根不会执行，看到的只是 shell 层报错。
诊断通过 ≠ 能装包，还有两个隐藏关卡
composer diagnose 通过只代表基础环境可用，但实际安装仍可能失败：
- 它不校验
composer.lock文件是否与composer.json一致，那得靠composer validate - 它不检查依赖约束是否过宽，比如
"monolog/monolog": "^1.0 || ^2.0 || ^3.0"会让求解器卡在Resolving dependencies阶段十几秒以上——这和网络无关，换镜像也无效 - 若提示
open_basedir restriction in effect，说明 PHP 配置限制了 Composer 访问临时目录（如/tmp），需调整open_basedir设置
真正要验证“能不能装包”，最简方式是 composer create-project --no-install --quiet test/test（空项目），看是否能跳过下载直接生成结构。否则，别只信 diagnose 的 OK。
