应通过composer why查依赖源头、php -v和php -m确认运行时环境是否原生支持，再在根composer.json中用"replace": {"symfony/polyfill-php80": "*"}精准剔除冗余polyfill，并执行composer update --lock和dump-autoload -o生效。
废弃 PHP 版本上的 polyfill 不是“装得越多越安全”，而是装错、装多、不清理，反而拖慢 autoload、增大 vendor 体积、引发函数覆盖冲突——尤其当你已升级 PHP 或启用原生扩展后。
怎么确认哪些 polyfill 已冗余？
别靠猜，用命令直接查依赖源头：
- 运行
composer why symfony/polyfill-php80，看输出是否为空；若返回某包（如laravel/framework），说明它仍显式依赖该 polyfill - 检查当前 PHP 版本：
php -v，若已是 PHP 8.0+，则symfony/polyfill-php80理论上不再需要（除非项目里还用了str_starts_with()但没升级到 PHP 8.0+ 的 runtime） - 检查扩展是否已启用：
php -m | grep mbstring，若存在，symfony/polyfill-mbstring就可被 replace - 注意：polyfill 是否冗余，取决于「运行时环境」而非「开发时 PHP 版本」——CI/部署环境才是最终判断依据
replace 配置写不对，等于没写
replace 字段必须写在项目根目录的 composer.json 中，且格式严格：
- 键名必须是完整包名，如
"symfony/polyfill-php80"，不能缩写或漏 vendor - 值推荐用
"*"（表示“任何版本我都原生支持”），而不是"self.version"（仅对 polyfill 自身元包有效，不适用于你的项目） - 不要把
replace写进子包的composer.json——它只在 root project 生效 - 写完立刻执行
composer update --lock，否则composer show仍会列出该包
为什么删了 polyfill 还报 Call to undefined function？
常见原因不是没删干净，而是 autoload 没刷新或函数被提前加载：
- 执行
composer dump-autoload -o后，检查vendor/composer/autoload_files.php是否还包含polyfill-*/bootstrap.php路径 - 确认入口文件（如
index.php）只引入一次vendor/autoload.php——重复 require 会导致function_exists()判断失效，触发重复定义警告 - 某些框架（如旧版 Laravel）会在启动阶段手动
requirepolyfill bootstrap，这种硬编码要手动清理，replace对它无效 - 如果用了 opcache，记得
opcache_reset()或重启 PHP-FPM，否则旧的 autoload 映射仍在内存中
上线前最容易被忽略的一件事
不是加 replace，而是验证 function_exists() 在生产环境真实返回 false ——比如你 replace 了 symfony/polyfill-mbstring，但生产机确实没装 ext-mbstring，那 mb_strlen() 就真没了。替换和移除是两回事，replace 只告诉 Composer “别装”，不保证功能存在。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
