弃用提醒不是错误但预示兼容性风险，需定位源头：含文件路径行号属依赖包问题，含Package::getNames()等为Composer或插件API弃用，无上下文则先禁用插件验证；再通过composer show、depends、autoload检查锁定并替换包，注意命名空间、方法签名及缓存刷新。
弃用提醒（Deprecated warning）不是错误，但它是明确的兼容性风险信号——它不会让你的代码立刻崩，但下次 PHP 升级或 Composer 更新后可能直接失效。别想着“关掉就行”，得定位源头、判断归属、再动手。
怎么区分是 Composer 自身还是依赖包在报 deprecated？
关键看警告内容里有没有文件路径和行号：
- 如果警告像
Deprecated: Function mcrypt_encrypt() is deprecated in /path/to/vendor/some-lib/legacy.php on line 123：这是 vendor 里的某个包调用了 PHP 已弃用函数，和 Composer 无关 - 如果警告像
Deprecated: Package::getNames() is deprecated, use getPackageNames() instead或含PluginInterface::activate()：大概率是 Composer v2.5+ 自身或某个插件用了旧 API - 如果警告只出现在
composer update -v输出末尾、没具体上下文：先跑composer update --no-plugins，警告消失就说明是插件问题
如何快速锁定触发警告的具体包？
别靠眼睛扫，用命令把源头打出来：
- 复现警告场景时加 PHP 参数：比如 Laravel 项目启动报错，就运行
php -d error_reporting=E_ALL artisan tinker，PHP 会输出完整路径+行号 - 查依赖树：运行
composer show --tree | grep -A5 -B5 "old-package"，确认它是直接 require 还是被aws/aws-sdk-php这类父包拖进来的 - 查谁在依赖它：运行
composer depends old/package，输出非空就说明有上游包硬绑着它，不能直接删 - 检查 autoload 是否残留：执行完 remove 后，翻
vendor/composer/autoload_classmap.php，搜旧类名，确保已清空
替换废弃包时最常踩的三个坑
换包 ≠ 改个名字再 composer require 就完事，命名空间、方法签名、autoload 映射全可能断：
-
composer show old/package输出里若只有abandoned: true，没replaced by字段，别信 Packagist 页面右上角写的“Replaced by”——那只是作者填的，可能过期；以composer show输出为准 - 新旧包命名空间不一致（比如从
Old\Helper变成New\Util），use语句和new Old\Helper\Thing()全得手动改；建议先用phpstan/phpstan扫描旧类名调用点 - 有些“替代包”只是 PSR 接口（如
psr/log），你得额外composer require monolog/monolog才能跑起来；光加接口不加实现，运行时报Class not found
为什么 composer remove 后还报 Class not found？
因为 autoload 缓存没刷新，或者旧类映射还卡在内存里：
- 必须执行
composer dump-autoload -o，否则新包的 PSR-4 映射不会生效 - Laravel 项目还得补一句
php artisan clear-compiled（或php artisan optimize:clear），不然框架缓存会继续找旧类 - 如果用了 OpCache，记得
opcache_reset()或重启 Web 服务，否则即使 autoload 文件更新了，PHP 还在用旧字节码 - 某些 IDE（如 PhpStorm）会缓存类索引，改完后要手动
File → Reload project from Disk
真正难的不是找到哪个包该换，而是确认新包的每个方法行为是否和旧版一致——比如一个 Helper::format() 在新版里默认返回 null 而不是空字符串，这种差异不会报错，但会在某个凌晨三点的订单导出里悄悄漏数据。
