composer diagnose只检查Composer自身运行强依赖的扩展（如json、mbstring、openssl等），不解析composer.json中项目声明的ext-xxx要求；要检测项目级扩展缺失，应使用composer check-platform-reqs或composer install --dry-run。
composer diagnose 为什么有时“查不出来”缺扩展
它只检查 Composer 自身运行强依赖的几个扩展（json、mbstring、openssl、phar、filter、hash、zip、curl 或 openssl），不读 composer.json 里项目声明的 ext-xxx。比如你项目 require 了 "ext-gd": "*"，但 composer diagnose 完全不会报 GD 缺失——它压根不看这一行。
真正能暴露项目级扩展缺口的是：
-
composer check-platform-reqs（Composer 2.2+）：列出所有composer.json中声明的 PHP 版本、扩展、函数要求及其满足状态 -
composer install --dry-run：会完整解析require和require-dev，只要某个包写了"ext-zip": "*"而你没开 zip，立刻中断并报错
别指望 diagnose 替你兜底。它只是“Composer 能不能活”，不是“你的项目能不能跑”。
如何让 Composer 每次 install/require 都强制校验扩展
默认行为就是校验，但容易被绕过或忽略。关键在两点：
- 确保没设
platform覆盖项：检查composer.json的config.platform是否手动降级了扩展要求（如"ext-zip": "0"），这会让校验直接跳过 - 禁用
--ignore-platform-reqs：CI 脚本或本地调试中误加该参数，等于主动关掉校验开关；建议在 CI 配置里显式禁止该 flag - 验证 CLI 环境纯净性：运行
php -m | grep -E "zip|curl|gd|fileinfo"，再对比composer check-platform-reqs输出——两者不一致，说明php.ini加载路径错了
没有“自动开启校验”的开关，因为校验本就是默认且强制的。问题往往出在环境错配，而非 Composer 关掉了它。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Linux/macOS 下快速补全常见缺失扩展（CLI 模式）
先确认 Composer 用的是哪个 PHP：which php 和 php --ini 必须一起看。常见陷阱：
- Ubuntu/Debian：装包后必须运行
phpenmod zip curl mbstring xml（不是只apt install php-zip就完事） - CentOS/RHEL：用
yum install php-pecl-fileinfo补fileinfo（注意是pecl-前缀，不是php-fileinfo） - macOS + Homebrew：扩展名带版本号，如
brew install php@8.2-zip；装完要brew link php@8.2，否则php -m不显示 - Docker：Dockerfile 里必须用
RUN docker-php-ext-install zip gd fileinfo，apt install php-zip完全无效
装完别忘了重启终端（尤其 Windows 和某些 macOS shell），否则新 php.ini 不生效。
扩展已启用却仍报错？重点盯这三个地方
现象：php -m | grep zip 有输出，composer check-platform-reqs 却标 missing，或者 install 过程中调用 ZipArchive::open() 失败。
- 检查
extension_dir：运行php -r "echo ini_get('extension_dir');"，确认输出路径下真有zip.so（Linux/macOS）或php_zip.dll（Windows） - 看 ini 加载顺序：
php --ini输出的 “Scan for additional .ini files in” 目录下，是否有同名扩展被重复加载（如20-zip.ini和99-custom.ini都启用了 zip）导致冲突 - 容器或 CI 环境里缺底层库：例如 Alpine Linux 需先
apk add libzip-dev，再docker-php-ext-install zip；否则扩展虽加载，但ZipArchive构造失败
扩展“存在”和“可用”是两回事。Composer 的校验走到函数调用层才会暴露这类隐性缺陷，所以 --dry-run 通过 ≠ 实际能用。
