composer diagnose 是第一道必过门槛，它逐项检测PHP扩展、CA证书、缓存目录权限、网络连通性等底层运行条件，暴露install/update失败的根本原因，而非依赖冲突。
直接运行 composer diagnose，它会暴露所有影响命令执行的底层障碍——不是“能不能装包”，而是“连基本运行条件都成问题”。
为什么 composer diagnose 是第一道必过门槛
很多 composer install 或 update 失败，根本不是依赖冲突，而是 PHP 扩展缺失、CA 证书失效、缓存目录不可写、甚至临时文件夹被 open_basedir 锁死。这些错误在 install 过程中往往表现为模糊报错（如 file_get_contents(): php_network_getaddresses: getaddrinfo failed），但 diagnose 会逐项点名。
- 它检查
composer.json和composer.lock的 JSON 合法性，避免因手改 JSON 多了个逗号就静默失败 - 验证 openssl、zlib、json、mbstring 是否真可用（
php -m只显示已加载，diagnose会实际调用测试） - 探测
~/.cache/composer是否可写；若你用sudo composer，它会明确警告“don’t run as root” - 尝试连接 packagist.org —— 若你已配置阿里云镜像，它报 ERROR 不代表异常，得配合
composer config repo.packagist确认是否生效
composer show --platform 查的是 Composer 实际依赖的运行时环境
这个命令输出的不是 PHP 配置文件里的“理论上支持”，而是 Composer 当前进程真实加载的扩展列表，包括版本号和 CLI/FPM 差异（比如 pcntl [dev] 表示仅 CLI 可用）。如果你的 composer.json 声明了 "ext-gd": "*" 却安装失败，这里没列出 gd 就是铁证。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 输出里不含
openssl？说明 CLI PHP 的php.ini没启用该扩展，哪怕 Web 端能用也不行 - Docker 或多 PHP 版本环境里，务必确认执行
composer时调用的是哪个php：先which php，再php --ini，最后composer show --platform - 加
--format=json可导出结构化快照，方便发给同事或 CI 日志比对
别跳过 composer validate 和 composer config -l
validate 专盯锁文件一致性：它会校验 composer.lock 里记录的所有包，是否仍在 composer.json 的 require 或 require-dev 中声明。若你手动删了 composer.json 里的某行却忘了 update，validate 会立刻报 Required package "xxx" is not present in the lock file。
-
config -l显示当前生效的全部配置（含全局和环境变量叠加结果），但不标注来源；想确认镜像源是否生效？composer config -l | grep repo - 敏感字段（如
http-basictoken）默认被隐藏，需加--show-passwords才可见 - 输出中标有
(global)的项，说明来自~/.composer/config.json，不是项目级设置
真正容易被忽略的点是：这些命令本身也依赖环境。如果 composer diagnose 报 “git not found”，那后续所有涉及 dev- 分支的操作都会卡住；如果 composer show --platform 缺 phar 扩展，连 composer.phar 都无法解包执行。检测不是走流程，是确认 Composer 脚本能否在当前上下文里真正落地。
