Composer不处理弃用警告，真正触发的是PHP运行时E_DEPRECATED；需通过php -d error_reporting=E_ALL、composer depends和composer show定位问题包，再升级或替换依赖，而非关闭错误报告。
废弃特性兼容性异常不是 Composer 的 bug，而是 PHP 解析器在执行代码时抛出的 E_DEPRECATED——它暴露的是你项目里、依赖包中或插件脚本里调用了已被 PHP 标记为弃用的函数或语法。不能靠关日志来解决，得定位到具体调用点再修复。
怎么判断是哪个包在触发 deprecated 警告
关键看警告信息里有没有文件路径和行号：
- 如果像
Deprecated: Function each() is deprecated in /path/to/vendor/old-lib/src/Helper.php on line 45：说明是old-lib这个依赖包内部用了 PHP 7.2 就已弃用的each()，和你的代码无关，但必须升级或替换它 - 如果像
Deprecated: Package::getNames() is deprecated, use getPackageNames() instead：大概率是某个 Composer 插件（比如composer-plugin-apiv1.x）调用了旧版接口，需查composer show --plugins - 如果警告只出现在
composer update -v输出末尾、没上下文：先跑composer update --no-plugins，警告消失就说明是插件问题
快速锁定源头的三个命令
别靠肉眼扫日志，用这些命令直接定位：
-
php -d error_reporting=E_ALL composer update -v 2>&1 | grep -A2 -B2 "Deprecated"—— 强制显示所有弃用提示，并带上下文行 -
composer depends vendor/package-name—— 查谁依赖了疑似有问题的包，确认是否上游硬绑定 -
composer show vendor/package-name—— 检查输出里是否有abandoned字段；同时打开 Packagist 页面 看右上角有没有 “Replaced by”
替换废弃包时最容易断掉的地方
换包不是改个名字再 composer require 就完事，以下三处常被忽略：
立即学习“PHP免费学习笔记（深入）”；
- 命名空间变更：
use Old\Util\Helper可能变成use New\Tool\Runner，autoload 映射也得同步改 - 方法签名不兼容：
Helper::run($config)可能变成Runner::execute(array $config): void，参数顺序、类型、返回值全不同 - 接口与实现分离：有些新包只提供 PSR 接口（如
psr/log），你得额外装一个实现（如monolog/monolog），否则new Logger()直接报错
临时压制警告的边界在哪
仅限调试或 CI 日志清理，绝不能用于生产环境：
- 入口文件顶部加
error_reporting(E_ALL ^ E_DEPRECATED);—— 最小影响范围，上线前必须删掉 - CI 中用 phpunit.xml 配置：
<ini name="error_reporting" value="24575"/>（即E_ALL & ~E_DEPRECATED） - 绝对不要改
php.ini全局关E_DEPRECATED，否则下次升 PHP 版本时会漏掉更严重的兼容性断裂
真正麻烦的不是警告本身，而是那些没报错但行为已变的弃用项——比如 mb_ereg_replace() 第三个参数 en 在 PHP 8.1+ 被移除，不报错但正则逻辑失效；又比如静态调用非静态方法，在 PHP 8.0 下只是警告，PHP 8.2+ 可能直接 fatal。这类问题必须靠测试覆盖+逐行检查，没法靠 Composer 自动发现。
