composer diagnose 只检查 composer 自身运行环境是否正常，不检查依赖存在性、版本冲突、platform 匹配、autoload 文件实际存在、插件兼容性或脚本执行性；它仅验证 php 版本及 json/openssl/zip/phar 扩展、composer.json/.lock 合法性、vendor 可写性、packagist.org/github 连通性、ca 证书可信度。
composer diagnose 不是安装检查器，也不是依赖分析器——它只回答一个问题：Composer 自身能不能安全启动。
为什么 composer diagnose 显示 OK 却 composer install 直接失败
它不验证你项目真正依赖的任何东西：
-
composer.json里写了"ext-redis": "*"，但系统根本没装或没启用redis扩展 →diagnose完全不查，install在解包后第一行new Redis()就 fatal error - 配置了
"config": {"platform": {"php": "8.2.0"}}，末尾多了个.0→diagnose认为合法，update却报platform config is invalid - 用了阿里云镜像，但
repositories.packagist.org.url少了个结尾/→diagnose显示Repo is default，实际请求全走官方源，限流+超时 -
"psr-4": {"App\": "src/"}，但src/下压根没有App/目录 →diagnose不扫描文件系统，vendor/autoload.php一require就Class not found
composer diagnose -v 和 composer diagnose --strict 的真实作用边界
两者作用域完全不同，混用反而误导：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
-v（或--verbose）只是把每项检查的判断依据打出来：比如具体哪个目录权限不够、CA 证书路径在哪、GitHub rate limit 剩多少次、Git 用户名是否为空 -
--strict是把原本 warning 级的问题（如composer.lock is not up to date）当 error 退出，但它不验证 lock 文件内容是否损坏，只比对时间戳 - CI 脚本里慎用
--strict：你正准备跑composer update，lock 过期反而是预期状态，结果 CI 直接挂掉 - 两者不叠加生效：
--strict不会让-v多显示一项，-v也不会让--strict多检查任何新东西
哪些问题 composer diagnose 根本不碰，必须手动补位
它跳过所有需要真实执行、解析或发网络请求的环节：
- 不验证 PHP 扩展是否真正可用：比如
openssl模块已加载，但被disable_functions = openssl_encrypt禁了 →diagnose仍显示 OK - 不检查
memory_limit：install卡死在解压 ZIP 包时，diagnose一句提示都没有 - 不探测私有仓库：即使
repositories里写了内网地址且 DNS 不通，只要没配 GitHub token，它就不发请求，直接标 OK - 不测试 autoload 是否生效：PSR-4 映射路径下文件缺失、命名空间拼错、大小写不一致 → 全部放过
- 确认方法：用
php -m | grep -E "openssl|zip|mbstring"和php --ini手动核对 CLI 模式下的配置
最常被忽略的点是：它默认不校验 CA 证书路径是否真能被 PHP 的 OpenSSL 使用——diagnose 说 “OK”，可能只是因为 curl 能连通 packagist.org 的 HTTP 端口；而实际 HTTPS 请求（比如私有仓库、GitHub API）会卡在 cURL error 60。这事得靠 php -r "print_r(openssl_get_cert_locations());" 和 curl -I https://packagist.org/packages.json 交叉验证。
