Composer不检测弃用特性，需用phpcompatibility+phpcs扫描源码；composer show --platform-check仅比对扩展是否加载，不识别mysql_connect()等@deprecated函数或ext-mcrypt等已弃用扩展的调用。
Composer 本身不做静态分析，也规避不了任何 PHP 扩展的兼容性缺陷——它连“不推荐使用”都感知不到。你真正需要的不是 Composer 命令，而是 phpcompatibility/php-compatibility 配合 phpcs 对源码做语法级扫描。
composer show --platform-check 根本不查“不推荐使用”
这个命令只比对 composer.json 里写的 require.ext-xxx 和当前 PHP 是否加载了同名扩展，完全不管：
- ext-mcrypt 已被弃用多年，但只要
"ext-mcrypt": "*"写在 require 里，且扩展还挂着，composer show --platform-check就显示 OK - ext-xmlrpc 在 PHP 8.4 中被移除，但如果你的 composer.json 锁的是
"php": "^8.1"，它照样允许安装依赖，不报任何警告 - ext-apcu-bc 是兼容层，但
composer不知道它只是个垫片，也不会提醒你apc_fetch()在新版 APCu 下行为已变
哪些“不推荐使用”的扩展问题只能靠静态扫描发现
PHP 官方标记为 @deprecated 的函数、类或扩展特性，不会触发 Composer 任何校验，但会在运行时报 E_DEPRECATED（或被静默禁用）。常见案例如下：
-
mysql_connect()（ext-mysql，PHP 5.5+ deprecated，7.0+ 移除）→phpcs扫描能直接标出调用行 -
DOMDocument::loadXML()在 PHP 8.3+ 默认启用LIBXML_NONET，旧代码若依赖网络加载会失效 → 需结合libxml_disable_entity_loader(true)检测，phpcompatibility规则集已覆盖 -
ext-json中JSON_ERROR_UTF8常量在 PHP 7.2+ 被JSON_INVALID_UTF8_IGNORE替代 →phpcs可识别未定义常量引用
怎么用 phpcs + php-compatibility 扫描“不推荐使用”的扩展调用
步骤极简，但必须手动指定目标 PHP 版本，否则默认只扫 PHP 5.6 兼容性（对现代项目毫无意义）：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 安装：运行
composer require --dev phpcompatibility/php-compatibility squizlabs/php_codesniffer - 扫描全部代码并标记所有 deprecated 用法（以 PHP 8.2 为目标环境）：
vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 8.2 src/ - 重点看输出中含
Deprecated或Removed字样的警告，例如：PHP 8.2+ - Function mysql_connect() is deprecated - 若想只聚焦扩展相关警告，加
--sniffs=PHPCompatibility.PHP.DeprecatedExtensions
别指望 config.platform 伪造扩展存在能绕过 deprecated 检查
"config": {"platform": {"ext-mcrypt": "1.0"}} 只会让 Composer 在解析依赖时假装 ext-mcrypt 存在，但它：
- 不阻止
phpcs扫出mcrypt_encrypt()调用 - 不屏蔽运行时
E_DEPRECATED日志（除非 error_reporting 关了） - 无法修复 ext-xmlrpc 在 PHP 8.4 下彻底消失的事实
真正要落地兼容，得删掉调用、换用 openssl_encrypt() 或 curl，而不是让 Composer “假装它还在”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
