composer diagnose 显示 ok 却 install 失败，因其仅检查 composer 自身安全启动能力，不验证 php 扩展、版本、私有仓库连通性、platform 配置真实性及 autoload 等实际依赖条件。
composer diagnose 为什么显示 OK 却 install 失败
因为 composer diagnose 只检查 Composer 自身能否“安全启动”，不校验你项目里 require 的扩展、PHP 版本、私有仓库连通性或 platform 配置真实性。它通过 ≠ 依赖能装上。
-
composer.json写了"ext-redis": "*"，但系统没装 redis 扩展 →diagnose不报错，install直接中断 - 配置了
"config": {"platform": {"php": "8.2.0"}}（末尾多了个.0）→diagnose认为合法，但update会报platform config is invalid - 用了阿里云镜像但 URL 少了末尾
/→diagnose显示Repo is default，实际走的还是官方源，下载慢还可能限流 - CI 环境中
~/.composer/config.json是 root 创建、当前用户无读权限 →diagnose跳过全局配置检查，却仍尝试用失效 token 访问 GitHub API
加 -v 和 --strict 到底有什么区别
-v（或 --verbose）让你看见“它到底在查什么”，--strict 则把警告当错误——但二者作用对象完全不同，混用容易误判。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer diagnose -v会输出每项检查的细节：比如具体哪个目录权限不足、CA 证书路径在哪、GitHub rate limit 剩多少次、Git 用户名是否为空 -
composer diagnose --strict把原本只是 warning 的问题（如composer.lock is not up to date）升级成 error，但它**不检查 lock 文件内容是否损坏**，只看时间戳 - 两者不叠加生效：
--strict不让-v显示更多项，-v也不让--strict多检查任何新东西 - CI 脚本里慎用
--strict：它会把“lock 文件不是最新”这种提示当失败，而你可能正准备跑update，这反而是预期状态
哪些问题 diagnose 根本不查，必须手动补位
composer diagnose 是轻量级自检，不是环境审计工具。它跳过所有需要真实执行、解析或网络请求的环节。
- 不验证 PHP 扩展是否启用：比如
openssl模块已加载但被禁用（disable_functions = openssl_encrypt），diagnose仍显示 OK - 不检查
memory_limit是否够用：install卡死在解压 ZIP 包时，diagnose一句提示都没有 - 不测试 autoload 是否生效：PSR-4 映射路径下文件缺失、命名空间拼错，
diagnose完全不管 - 不探测私有仓库：即使
repositories里写了内网地址且 DNS 不通，只要没配 GitHub token，它就不发请求，直接标 OK - 确认方法：用
php -m | grep -E "openssl|zip|mbstring"和php --ini手动核对 CLI 模式下的配置
CI/CD 中怎么用 diagnose 才不白跑
在自动化流程里，composer diagnose 必须配合其他检查才有意义，单独运行容易产生虚假安全感。
- 先确保你在项目根目录（含
composer.json的目录）运行，否则它不会查你的vendor/权限和本地配置 - 加
-v并重定向日志：composer diagnose -v > diagnose.log 2>&1，方便出问题时回溯 Git 配置、CA 路径等细节 - 必须搭配
test -f composer.lock：如果diagnose过了但没 lock 文件，说明流程漏了composer update或提交，这不是环境问题，是流程缺陷 - 别信
github.com rate limit: OK：它只查当前 token 剩余请求数，不验证 token 是否有效。CI 中应优先用composer config --global github-oauth.github.com $TOKEN注入，而非依赖 auth.json 文件存在 - 某些共享主机禁用
proc_open()，diagnose会跳过网络检测并输出Skipped—— 这不是通过，是无法验证，得单独加 curl 测试
diagnose 报出来的红字，而是它根本没查、却在 install 时突然爆发的那些点。
