composer diagnose 检查 Composer 运行环境是否干净可靠，包括 composer.json 语法、vendor 完整性、Git 配置、CA 证书可信度及远程仓库连通性；加 -v 显细节，--strict 提升警告为错误，--working-dir 限定作用域，但不验证 PHP 扩展或 memory_limit。
composer diagnose 检查什么
它不是跑测试，也不是修依赖，而是快速验证 Composer 自身运行环境是否「干净可靠」。重点检查：本地 composer.json 语法、vendor 目录完整性、Git 配置是否干扰、CA 证书是否可信、远程仓库（如 packagist.org）能否连通。
常见错误现象：composer install 卡在「Loading composer repositories」、composer update 报 cURL error 60、明明改了 composer.json 却提示「No lock file found」但实际有 composer.lock——这些都值得先跑一遍 composer diagnose。
怎么让 diagnose 输出真正有用的信息
默认只报严重问题，容易漏掉隐患。加 -v 或 --verbose 才能看到 Git 配置、HTTP 超时、SSL 验证路径等细节：
composer diagnose -v
如果项目用了私有仓库或自建 Packagist，记得加上 --no-interaction 避免卡在认证提示；CI 环境里还建议加 --strict，让非致命警告也当错误退出（比如 vendor 中有未声明的包）。
-
--strict：把「警告」转成「错误」，适合自动化流程 -
-v：暴露底层网络和 Git 行为，定位超时/证书/代理问题的关键 - 不加任何参数时，它甚至不会检查
composer.lock是否过期，别被「OK」骗了
诊断通过 ≠ 环境真的 OK
它不验证 PHP 扩展是否启用（比如 openssl、zip），也不检查 memory_limit 是否够用——这些得靠 php -m 和 php --ini 手动确认。
更隐蔽的坑是：Windows 下 Git Bash 用户常遇到 diagnose 显示「Git is installed」但后续 composer install 仍失败，原因是 Git 的 core.autocrlf 设置导致 vendor 中文件权限或换行符异常。此时要额外跑：git config --global core.autocrlf false。
- CA 证书问题在 macOS 上高频出现，
diagnose只说「SSL certificate problem」，实际要更新ca-certificates或配置composer config -g cafile /path/to/cert.pem - 使用代理时，
diagnose不校验代理本身是否生效，只测最终能否连上 packagist.org；得自己curl -v https://packagist.org/packages.json对比
CI/CD 里怎么安全用 diagnose
别直接 composer diagnose --strict 就完事。它默认会尝试读取全局配置（~/.composer/config.json），而 CI 容器里这个文件可能不存在或含敏感 token。
推荐显式指定作用域：
composer diagnose --no-interaction --strict --working-dir ./
这样强制只检查当前目录下的 composer.json 和 vendor，不碰全局状态。如果项目没 vendor（比如首次构建），加 --skip-all 跳过 vendor 校验，否则会误报「vendor directory does not exist」。
-
--working-dir是关键，避免误读父目录或全局配置 -
--skip-all可跳过 vendor、git、https 等全部子项，适合极简检查 - CI 日志里看到
Checking git settings: OK别放心——它只是检查git --version能否执行，不保证git clone权限正确
