弃用警告源于PHP运行时（如E_DEPRECATED），非Composer本身问题；它暴露的是项目代码、依赖包或插件中调用mcrypt_encrypt()、each()、未声明返回类型等不符合PHP新规范的代码，需定位并修复源头。
弃用函数警告不是 Composer 的问题，它只是把 PHP 运行时暴露的 E_DEPRECATED 提到了你面前——真正要修的是你加载的代码里调用了 mcrypt_encrypt()、each()、create_function() 或没声明返回类型的 current(): mixed 这类东西。
为什么 composer install/update 会报 Function X is deprecated？
Composer 自身在 PHP 8.0+ 下已无弃用问题（2.x 全面兼容），这些警告实际来自：
- 你在
composer.json的require-dev里装了老旧插件（比如phpunit/phpunit7.x、sebastian/environment3.x） - 某个依赖包（如
monolog/monolog1.x、doctrine/collections1.x）在vendor/里直接调用了弃用函数 - 你自己的
autoload-dev脚本或测试启动文件里写了__autoload()或mb_ereg_replace(..., 'en') - PHP 8.1+ 环境下，某个迭代器类没给
key()、current()加返回类型声明，触发ReturnTypeWillChange警告
怎么快速定位是哪个包在调用弃用函数？
别靠猜。用这两招直接锁定源头：
- 运行
composer update -v 2>&1 | grep -A3 -B3 "Deprecated"，看 verbose 输出里哪一行最先出现警告路径 - 临时启用全错误报告跑一次触发场景：
php -d error_reporting=E_ALL index.php或php -d error_reporting=E_ALL vendor/bin/phpunit，从堆栈第一行非你代码的vendor/xxx/src/YYY.php反推包名 - 确认后执行
composer show vendor/name查当前版本，再翻它的 GitHub Releases 页面搜ReturnTypeWillChange或PHP 8.1
升级失败或没新版时，能不能先压住警告？
可以临时压制，但必须清楚代价：
立即学习“PHP免费学习笔记（深入）”；
- 开发调试：在入口文件（如
index.php或artisan）顶部加error_reporting(E_ALL ^ E_DEPRECATED); - CI 流程中避免日志刷屏：在
phpunit.xml里写<ini name="error_reporting" value="24575"/>（E_ALL & ~E_DEPRECATED） - 绝对不要在
php.ini里全局关掉E_DEPRECATED——这会让后续升级 PHP 版本时漏掉更严重的问题 -
--no-warnings或重定向stderr只是藏起来，运行时照样崩，且掩盖真实风险
“Package X is abandoned” 警告该怎么应对？
这不是函数级警告，而是维护状态预警，处理逻辑完全不同：
- 先跑
composer show vendor/package，看abandoned字段值是true还是具体包名（如"spatie/laravel-permission"） - 如果是间接依赖，用
composer depends vendor/package查谁在拖它进来；再查上游是否已发新版支持替代方案 - 替换时重点核对
autoload命名空间变化——旧包用Old\Ns\，新包可能改成了New\Ns\，不改use语句必报Class not found - 无法立刻迁移？可在根项目
composer.json中加"replace": {"old/package": "self.version"}显式接管，但得自己担起补丁责任
最常被忽略的一点：所有弃用警告都指向同一事实——你正在运行的某行 PHP 代码，已经不符合当前语言规范。Composer 不生产警告，它只是那个提醒你该翻翻 vendor/ 里谁还在用 each() 的人。
