Composer环境检查：为什么说composer show --platform比php -m更可靠？
先说结论：想快速摸清Composer运行时到底认哪些扩展，最直接的办法就是运行composer show --platform。这个命令给出的清单，往往比翻php.ini或者盲目猜测报错原因要准确得多。
为什么composer show --platform比php -m更可靠？
关键在于，它做的远不止“检查扩展是否加载”这么简单。这个命令实际上模拟了Composer自身的解析与校验逻辑。这意味着，它会主动过滤掉那些被禁用的ini配置、忽略未生效的extension=指令，甚至能识别出因底层库版本不匹配而“静默失效”的扩展——比如ext-intl扩展虽然加载了，却因为ICU库版本问题无法正常工作。
一个典型现象就是：php -m | grep intl明明显示intl存在，但在composer show --platform的输出列表里却找不到它。这恰恰说明，该扩展虽然被PHP加载了，却未能通过Composer的功能性校验。
php -m只反映了PHP进程启动时加载了哪些模块，并不保证这些模块能被Composer正常调用。composer show --platform展示的，才是Composer运行时真正“认可”的那套环境，包括所有可用的ext-*扩展、lib-*库以及PHP版本本身。- 它自动帮你绕开了CLI与Web环境配置混淆的坑——你不需要先运行
php --ini查路径，再手动比对不同配置文件。
当composer diagnose报扩展缺失，但show --platform里却有它
遇到这种情况，通常意味着扩展文件虽然存在，但可能在运行时“掉了链子”。ext-zip或ext-curl就是常客：模块加载了，但实际无法执行解压或发起HTTPS请求等核心功能。
composer diagnose会进行运行时探测，例如尝试调用zip_open()或curl_init()这类函数，一旦失败就会报告“missing”。- 这时可以手动验证：运行
php -r "var_dump(function_exists('zip_open'));"，如果返回bool(false)，那就不是模块没加载，而是关键函数不可用。 - 在Linux或macOS上，这常常源于系统级依赖缺失。比如
ext-zip扩展依赖libzip库，如果只安装了PHP扩展而没装底层库，功能照样瘫痪。 - Docker Alpine用户尤其要注意：
apk add php82-zip必须搭配apk add libzip一起执行，否则composer diagnose依然会失败。
Windows环境下：改了php.ini，为何show --platform还是不显示扩展？
十有八九，是CLI环境读取的配置文件并非你修改的那一个，或者扩展的物理路径根本不对。
这里有几个排查方向：
- 首先，运行
php --ini，紧盯Loaded Configuration File这一行显示的路径。别完全相信XAMPP等集成环境控制面板里显示的“主配置文件”。 - 确认扩展目录是否正确：执行
php -r "echo ini_get('extension_dir');"，然后进入该目录，查看对应的DLL文件（例如php_mbstring.dll，注意不是mbstring.dll）是否存在。 - 像Laragon或XAMPP这类工具，常会为CLI单独生成一个
php-cli.ini，其优先级高于php.ini。改错了文件，等于白忙活一场。 - 扩展文件名必须严格匹配PHP版本。例如，为PHP 8.2编译的
php_intl.dll，如果被放在一个仍配置着PHP 8.1版本DLL文件的php.ini里，运行时可能会加载失败且不报任何错误，让人无从下手。
需要警惕的是，Composer判断一个扩展是否“存在”，标准非常严格：它不看ini里有没有那行配置，也不看php -m有没有输出，而是看它在运行时能否安全、稳定地调用该扩展的核心函数族。举个例子，哪怕ext-xml显示已加载，只要系统libxml库版本过低，导致simplexml_load_string()这类函数内部崩溃，Composer就会毫不犹豫地将它判定为“缺失”。这才是问题的关键所在。
