composer outdated 不报 API 过期，因它仅比对版本号与 Packagist 最新稳定版，不解析 PHP 代码、不读 @deprecated 注释、不查 CHANGELOG；探测废弃接口需 phpstan、psalm 等静态分析工具。
Composer 本身不提供“过期 API 调用”的探测能力——它只管包版本，不管代码里用了哪些函数或类。所谓“过期 API”，必须靠静态分析或运行时检测，不是 composer outdated 能解决的问题。
为什么 composer outdated 完全不报 API 过期？
它只比对 composer.lock 中记录的版本号和 Packagist 元数据里的最新稳定版，不解析 PHP 代码、不读 CHANGELOG、不查弃用（@deprecated）注释。比如你代码里还在调 Symfony\Component\HttpFoundation\Response::create()，而 Symfony 6.4 已标记该方法为废弃，composer outdated 不会提一个字。
- 它不知道你项目里有没有写
use或new某个类 - 它不扫描
.php文件，也不执行 AST 分析 - 即使你升级了包，
outdated也不会告诉你“这个方法下周就删了”
真正能探测过期 API 的工具组合
要发现实际代码中调用的废弃接口，得用外部工具配合包元数据：
-
phpstan+phpstan-deprecation-rules：在类型检查阶段捕获@deprecated标记的调用，支持自定义规则匹配别名、迁移路径 -
psalmwith--show-info：默认报告弃用，可配合psalm-plugin-symfony理解框架特定生命周期 -
phpcs+SlevomatCodingStandard：检查@deprecated注释是否被遵守，但需手动维护规则库 -
composer show vendor/package：看输出里是否有abandoned字样和replacement提示，这是包级弃用信号，不是 API 级
注意：composer audit 只查 CVE，composer depends 只查依赖链——它们都不碰你的 PHP 代码。
重构前必须确认的三件事
别一看到“deprecated”就改。先验证它是否真影响你：
- 运行
grep -r "Response::create" . --include="*.php"，确认调用点是否真实存在（有些只是配置字符串或注释残留） - 查上游 CHANGELOG：比如
symfony/http-foundation的 v6.4.0 版本日志里明确写了 “Response::create()is deprecated, useResponse::create()→new Response()instead” - 用
composer show symfony/http-foundation确认当前安装版本，再对比目标升级版本的弃用列表（如 v6.4 vs v7.0）
很多“过期 API”只存在于 dev 分支文档里，稳定版尚未生效；或者仅影响特定 PHP 版本（如 PHP 8.3+ 才触发弃用警告）。
CI 中自动化探测的最小可行方案
把静态分析嵌入构建流程，而非依赖 Composer 命令：
- 在
.phpstan.neon里启用deprecationRules: true，并加ignoreErrors排除已知暂时无法修复的项 - CI 步骤写成：
vendor/bin/phpstan analyse --no-progress --configuration=phpstan.neon src/ || exit 1 - 避免用
composer outdated --all当 API 过期信号——它可能显示symfony/http-foundation 6.3.0 → 6.4.0，但你代码里根本没用到 6.4 新增或废弃的任何东西
真正的风险点永远在代码行里，不在版本号上。版本更新是机会，不是义务；API 弃用是信号，不是倒计时。
