答案是先执行php -m | grep xxx验证cli环境是否加载扩展，再用php --ini定位配置文件，最后运行composer check-platform-reqs精准识别缺失项；三步缺一不可。
composer install报错说“ext-xxx缺失”，先别急着装扩展
错误里写的ext-fileinfo、ext-gd这类提示，不是让你直接yum install php-fileinfo就完事。CLI模式和Web模式用的PHP配置可能完全不同，你看到浏览器里phpinfo()有这个扩展，不代表composer install能用上。
真正该做的三步是：
- 运行
which php确认Composer调用的是哪个PHP二进制 - 运行
php --ini盯住Loaded Configuration File那一行——比如/etc/php.d/99-composer.ini或/etc/php/8.2/cli/php.ini - 运行
php -m | grep fileinfo（把fileinfo换成你要查的扩展名）看它是否真在CLI加载列表里
如果php -m没输出，但phpinfo()里有，说明你改了FPM的php.ini，却忘了CLI那份。
用composer check-platform-reqs精准定位缺哪个扩展
composer check-platform-reqs才是唯一靠谱的检测命令。它不安装、不改配置，只比对composer.json里写的"ext-xxx": "*"和当前CLI实际加载的扩展。
执行后如果看到类似这样的输出：
ext-fileinfo MISSING
那就坐实了：缺的就是fileinfo，而且是CLI环境缺。
注意几个关键点：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 加
--no-dev能过滤掉require-dev里的开发扩展（比如ext-xdebug），避免干扰 - 如果
config.platform.ext-xxx写了版本约束，这个命令也会校验它是否真实可用 - 输出为空 ≠ 环境完美，只是你
require里声明的扩展都满足了；漏写ext-xxx会导致检测完全漏报
Linux下扩展已装但php -m不显示？检查启用机制
CentOS/RHEL系常见情况是：包装了，但没启用。比如yum install php-fileinfo成功后，php -m还是看不到fileinfo。
原因通常是：
-
/etc/php.d/fileinfo.ini文件不存在，或者存在但被注释掉了（开头有分号） - PHP版本切换后，新版本的
php.d目录路径变了，旧扩展没同步过去 - 某些发行版（如Ubuntu）要用
sudo phpenmod fileinfo启用，而CentOS靠的是.ini文件是否生效
临时验证方式：手动在CLI用的php.ini末尾加一行extension=fileinfo.so，再跑php -m看是否出现。
报错里夹着“Could not open input file”？可能是PHP根本没启动起来
这种报错看着像文件路径问题，实际往往是PHP二进制本身调用失败。Composer找不到php命令，就会退化成“打开composer.phar失败”这种误导性提示。
排查顺序必须是：
- 运行
command -v php，确认shell能识别php命令（比which php更可靠，能绕过alias） - 运行
php -v，看是否真能执行；如果报command not found或Segmentation fault，那Composer肯定起不来 - 如果PHP路径不在
$PATH里（比如Homebrew装的PHP在/opt/homebrew/bin/php），就设PHP_BINARY=/opt/homebrew/bin/php再试
Windows用户特别注意：php.exe路径含空格、杀毒软件拦截、或用了PowerShell alias，都会导致Composer启动时找不到PHP——哪怕php -v在终端里看起来一切正常。
