composer show --platform比php -m更可靠，因为它不只检查扩展是否加载，还模拟Composer解析逻辑，过滤被禁用、未生效或功能异常的扩展（如因ICU版本不匹配导致ext-intl静默失效），真实反映Composer运行时认可的可用扩展。
直接看结果：用 composer show --platform 就能列出当前 CLI 环境下 Composer 实际识别到的所有已启用扩展，比翻 php.ini 或猜报错更准。
为什么 composer show --platform 比 php -m 更可靠
它不只检查模块是否加载，还模拟 Composer 自身的解析逻辑——比如会过滤掉被禁用的 ini 文件、忽略未生效的 extension= 行、跳过因 ICU 版本不匹配而静默失效的 ext-intl。常见现象是 php -m | grep intl 能看到 intl，但 composer show --platform 里没有，这就说明 intl 扩展虽加载了，实际无法通过 Composer 的功能校验。
-
php -m只反映 PHP 启动时加载了哪些模块，不保证它们能被 Composer 正常调用 -
composer show --platform是 Composer 运行时真正“认”的那一套，包括 ext-*、lib-* 和 PHP 版本 - 它自动跳过 CLI 和 Web 配置混淆的问题——你不用先查
php --ini再手动比对
composer diagnose 报扩展缺失，但 show --platform 里有
这说明扩展存在，但可能没通过 Composer 的运行时探测。典型场景是 ext-zip 或 ext-curl 加载了，却无法解压或发起 HTTPS 请求。
-
composer diagnose会尝试调用zip_open()或curl_init()，失败就报“missing” - 检查
php -r "var_dump(function_exists('zip_open'));"，返回bool(false)就是函数不可用，不是模块没加载 - Linux/macOS 下常见于系统级依赖缺失，比如 zip 扩展依赖
libzip，但只装了 PHP 扩展没装底层库 - Docker Alpine 用户注意：
apk add php82-zip必须搭配apk add libzip，否则composer diagnose仍失败
Windows 下 php.ini 改了，show --platform 还不显示扩展
大概率是 CLI 读的不是你改的那个 php.ini，或者扩展路径根本不对。
立即学习“PHP免费学习笔记（深入）”；
- 运行
php --ini，重点看Loaded Configuration File这一行路径，别信 XAMPP 控制面板里显示的“主配置文件” - 确认
extension_dir值是否正确：php -r "echo ini_get('extension_dir');"，然后进该目录看是否存在php_mbstring.dll（不是mbstring.dll） - Laragon/XAMPP 常为 CLI 单独生成
php-cli.ini，它优先级高于php.ini，改错文件等于白改 - 扩展名必须严格匹配：PHP 8.2+ 的
php_intl.dll在旧版php.ini里写成php_intl.dll，但若你用的是 PHP 8.1 编译的 DLL，8.2 运行时会加载失败且不报错
最易被忽略的一点：Composer 对扩展的“存在性”判断，不是看 ini 有没有那行，也不是看 php -m 有没有输出，而是看它能否在运行时安全调用对应函数族。哪怕 ext-xml 显示已加载，只要 libxml 库版本太低导致 simplexml_load_string() 崩溃，Composer 就会把它当作“缺失”。
