能，composer outdated 能查到已安装的 composer 插件，但不区分插件类型，仅按普通包展示；若未显示某插件更新，通常因版本锁定、fork 源或未真正安装。
composer outdated 能查到插件吗？
能，但默认不区分——Composer 插件只要满足 type: "composer-plugin" 且已安装，就和其他包一样出现在 composer outdated 结果里。它不识别“这是插件”，只识别“这是已安装的包”。所以你看到的 sandersander/composer-link 或 kylekatarnls/update-helper 的更新提示，和 monolog/monolog 没本质区别。
常见错误现象：composer outdated 没列出某个插件，但你知道它有新版——大概率是该插件在 composer.json 中被写死版本（如 "sandersander/composer-link": "1.2.0"），或你用的是 fork 仓库源，而 outdated 默认仍比对 Packagist，结果不准。
- 确认是否真已安装：运行
composer show --plugin，只显示当前激活的插件（含其版本） - 想强制看全部插件状态：用
composer outdated --all | grep -i plugin - 注意：
require-dev里的插件也会被扫到，但上线环境通常不该依赖它们
为什么 update-helper 提示可升，outdated 却不显示？
因为两者判断逻辑不同。kylekatarnls/update-helper 是插件，在 composer update 后主动扫描「当前约束下理论上能升到的最高版」（哪怕超出 minor 兼容范围）；而 composer outdated 只报告「满足当前约束、且 lock 中版本更旧」的包——它更保守，也更贴近真实可安全执行的升级。
使用场景：日常巡检用 outdated --direct --minor-only 看稳妥项；主版本迭代前，再跑一次 update --dry-run + 看 update-helper 的提示，交叉验证。
-
outdated不显示symfony/console→v6.4.0，可能因为你锁着"^5.4"，v6 不在范围内 -
update-helper却会提醒：“你当前约束允许升到 v6.4.0，但需手动改 composer.json” - 这种差异不是 bug，是设计意图：一个管“能升”，一个管“该升”
怎么监控插件是否长期未更新？
靠人眼翻 outdated 输出不可靠，尤其 CI 场景。必须结构化提取 + 条件过滤。
实操建议（适用于 Composer 2.2+）：
- 只盯直接依赖中的插件：
composer outdated --direct --format=json | jq -r 'to_entries[] | select(.value.latest != .value.installed) | .key' | grep -E "(composer-link|update-helper|prestissimo)" - 加安全兜底：如果插件有已知漏洞，
composer outdated --security-only会标出[security]，但前提是该插件本身被 Packagist 官方收录并提交了 CVE - 避免误报：某些插件（如私有内网插件）没上 Packagist，
outdated始终显示 “n/a” 或跳过——这时得靠脚本比对 Git tag 或自建元数据服务
插件升级后为什么没生效？
因为 Composer 插件是“启动时加载”的，不是运行时热插拔。升级后必须让 Composer 重新初始化插件系统，否则旧逻辑还在内存里跑。
最容易被忽略的地方：
- 升级插件后，必须运行
composer dump-autoload（尤其当你改过插件自身的 autoload 配置） - 某些插件（如
composer-link）链接本地路径后，若目标包改了autoload规则，不手动 dump 就会静默失效 - 全局安装的插件（
composer global require）升级后，需确保当前项目用的 Composer 是同一份二进制（检查which composer），否则可能加载旧全局插件
插件不是装完就一劳永逸的东西，它的生命周期和 Composer 自身绑定得比普通包更紧——升级、调试、回滚，每一步都得考虑加载时机和 autoloader 状态。
