composer diagnose能发现php版本过低、openssl/phar扩展缺失、缓存目录不可写、github api限流等环境问题，但不检查项目级依赖、autoload、私有仓库连通性或memory_limit等实际运行条件。
composer diagnose 能快速暴露本地环境是否满足 Composer 正常运行的基本条件，但它不检查项目级依赖问题，只验环境底座——比如 PHP 版本、扩展、网络连通性、缓存路径权限等。跑完没报错 ≠ 项目能装包成功，但报错一定得先修。
哪些问题 composer diagnose 真的能发现
它不是万能扫描器，但对几类高频阻塞点很敏感：
-
openssl扩展未启用 → HTTPS 包源拉取失败的根源之一 - PHP 版本低于 Composer 最低要求（当前为 7.2.5+，但 Laravel 10+ 项目实际需 8.1+）
-
phar扩展被禁用 → Composer 自身无法解压执行 - 默认缓存目录（如
~/.composer/cache）不可写 → 后续install会卡在“Downloading”阶段 - GitHub API 限流或 DNS 解析异常 → 显示
github.com is available over HTTPS失败
怎么运行诊断？加什么参数更实用
直接运行即可，不需要项目上下文：
composer diagnose
但日常建议加 -v（verbose）看细节，尤其当某项标 FAIL 却不知原因时：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer diagnose -v
常见组合：
-
composer diagnose --no-interaction：CI/CD 流水线中静默执行，避免交互卡住 -
composer diagnose --profile：附带耗时统计，能看出是网络慢还是本地 IO 慢 - 不推荐加
--skip-script——它跳过 autoload 生成，但diagnose本身不触发脚本，加了无意义
看到 FAIL 怎么对应处理
错误信息里通常已提示具体缺失项，按字面查即可，但要注意几个易混淆点：
-
curl extension not loaded≠ 必须装curl扩展；Composer 优先用ext-curl， fallback 到ext-openssl+stream_context，所以只要后者 OK 就行 -
github.com is available over HTTPS: NO不一定是墙的问题——先ping github.com和curl -I https://api.github.com手动验证，可能是公司代理或 hosts 劫持 -
cache directory is not writable：注意检查父目录权限（如/home/user/.composer），而不仅是cache子目录 -
open_basedir restriction in effect：PHP 配置限制了可访问路径，需在php.ini中放宽或临时关闭该限制再跑 diagnose
真正麻烦的不是 diagnose 报的错，而是它没报——比如 vendor/autoload.php 路径被误删、composer.json 语法错误、或私有仓库认证配置漏写。这些得靠 composer validate 和手动试 require 来补位。
