composer outdated 只比对包版本号，不扫描代码或检查php函数弃用，无法识别create_function等废弃函数调用、php版本兼容性及间接依赖的弃用风险。
composer outdated 不查 PHP 函数弃用，它根本不知道 create_function 已废
composer outdated 只比对包版本号，不扫描 PHP 代码、不读 phpversion()、不查 Deprecated 警告。它看到 monolog/monolog 从 2.10.0 → 2.11.0，就标个红色补丁更新；但完全不管这个 2.11.0 是否已移除对 mcrypt_module_open() 的调用，也不管你项目里有没有手写 create_function()——这些和它的职责无关。
PHP 核心函数弃用（如 PHP 8.6 废弃 session_is_registered()、create_function()）影响的是运行时行为，不是 Composer 锁文件里的版本数字。哪怕 vendor 包的最新版已适配 PHP 8.6，只要你的代码或某层依赖还在用废弃函数，composer outdated 也不会提醒你。
vendor 包是否适配新 PHP 版本，得看它自己的 composer.json 和实际代码
一个包能否在 PHP 8.6 下安全运行，取决于三件事：
- 它的
composer.json中"require": {"php": "^8.0"}是否覆盖当前环境（比如你用的是php:8.6-cli） - 它是否在源码中主动检测并避开废弃函数（例如用
fn()替代create_function()） - 它是否依赖已被移除的扩展（如
ext-mcrypt在 PHP 8.2+ 已彻底删除）
composer outdated 不验证这三项中的任何一项。它只告诉你：“这个包在 Packagist 上有更高 stable 版”，仅此而已。你看到 guzzlehttp/guzzle 显示 7.8.1 → 7.9.0，不代表 7.9.0 就支持 PHP 8.6——得去翻它的 CHANGELOG.md 或跑 composer show guzzlehttp/guzzle 看 requires php 字段。
真正该用的命令组合：outdated + audit + PHP 静态分析
单靠 composer outdated 无法评估 PHP 升级风险。你需要叠加三层检查：
-
composer outdated --direct：先聚焦你直接 require 的包，缩小范围 -
composer audit --security-only：筛出已知 CVE 修复版（有些安全更新恰好也修复了废弃函数调用） -
./vendor/bin/phpstan analyse --level=8 src/或./vendor/bin/psalm --find-deprecations：这才是真正在代码里揪create_function()、mb_ereg()这类调用的地方
特别注意：composer outdated 输出的 latest 版本可能根本不兼容你目标 PHP 版本。例如你锁着 "laravel/framework": "^9.0"，outdated 显示 latest 是 9.52.16，但它可能要求 php >= 8.1，而你当前是 php 8.0 —— 这时 composer update 会失败，outdated 却不会预警。
最容易被忽略的点：间接依赖的弃用链
你代码没调 create_function()，不代表安全。某个你没直接 require 的包（比如 spatie/laravel-backup 依赖的 symfony/console）可能在内部用了废弃函数，而它的新版又没发布。这时 composer outdated 不会显示它，因为它的 latest 仍是 5.4.43（满足 "^5.4"），但这个 5.4.43 在 PHP 8.6 下实际会触发 Deprecated 警告。
这种场景下，composer depends symfony/console 能帮你定位谁在拉这个旧版；composer show symfony/console 查它的 requires php；再配合 grep -r "create_function" vendor/symfony/console/ 才能确认真实风险。别指望 outdated 自动串联这些线索。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
