过时的 PHP 框架插件无法仅靠 composer outdated 发现，须结合 composer show -l 查加载状态、composer why-not 定位冲突、Packagist 手动验证兼容性三步交叉确认。
直接结论：过时的 PHP 框架插件不能靠 composer outdated 全量发现，必须结合 composer show -l、composer why-not 和 Packagist 手动验证三步交叉确认。
为什么 composer outdated 常常漏掉插件？
插件（type: composer-plugin）不参与常规依赖解析流程，composer outdated 默认只检查 require 和 require-dev 中声明的包，而很多插件是通过 composer-plugin-api 动态注册、不走 autoload 的轻量实现。它们不会出现在默认输出里。
- 运行
composer show -l，带[plugin]标记的才是真实加载中的插件 - 如果某插件在
composer.json的require里，但show -l不显示，说明它没激活——常见于未执行composer install或插件类名注册失败 -
composer outdated --all可强制显示 patch 级更新，但对未声明为普通包的插件仍无效
如何定位某个插件的实际兼容版本？
Packagist 页面不是唯一依据，得看它是否真正支持你的框架版本和 PHP 运行环境。比如一个 Laravel 插件标称支持 “laravel ^9.0”，但实际代码里用了已被移除的 Illuminate\Support\Str::slug()（Laravel 10+ 改为 Str::of()->slug()），就会在运行时报错。
- 打开插件在 Packagist 的页面，点开
Source链接到 GitHub，重点看composer.json里的require和conflict字段 - 搜它的
CHANGELOG.md或UPGRADE.md，确认是否有明确的框架/PHP 版本适配说明 - 用
composer why-not vendor/plugin-name:latest查冲突路径，尤其注意是否卡在某个核心框架组件（如symfony/console或laravel/framework）的版本上
社区维护的替代方案怎么找？
别只盯着原插件的最新版，有些插件早已停止维护，但社区 fork 出了兼容分支。这类信息通常藏在 GitHub Issues 或 Packagist 的 “Suggests” 区域里。
立即学习“PHP免费学习笔记（深入）”；
- 在 Packagist 搜索插件名，点进详情页，往下拉看
Suggests和Replaces字段——比如phpunit/phpunit曾被phpunit/phpunit和phpunit/phpunit-mock-objects分拆，后者已废弃，但phpunit/phpunit自 v9 起内置了 mock 功能 - 在 GitHub 上搜
org:laravel plugin-name fork:true或plugin-name "fork of"，筛选最近一年有提交的活跃分支 - 警惕“看起来一样但没测试”的 fork：检查其
.github/workflows是否包含对应 PHP 版本和框架版本的 CI 测试
最容易被忽略的一点：插件是否真正生效，不取决于它有没有装进 vendor/，而取决于 composer show -l 是否列出 + composer dump-autoload 后能否调用其命令。很多“过时”问题其实是插件根本没加载成功，却被误判为版本不兼容。
