symfony/polyfill 是元包，不提供实际功能，需安装具体子包（如 symfony/polyfill-php80）并确保其 bootstrap.php 被 composer 自动加载；装错子包或加载链断裂会导致函数未定义。
装了 symfony/polyfill 却还是报 Call to undefined function？因为这个包本身不提供任何代码，它只是个“目录”，真正干活的是像 symfony/polyfill-php80 这样的子包——而且必须确保它们的 bootstrap.php 被 Composer 自动加载器触发。
为什么 composer require symfony/polyfill 没用
这个命令确实能成功执行，但什么都不会发生：它只是把一堆子包声明写进 composer.json 的 require 里，不下载、不注册、不定义函数。你看到的 vendor/symfony/polyfill 目录下空空如也，或者只有 composer.json 和 README.md。
-
symfony/polyfill是元包（metapackage），没有autoload.files，也没有任何 PHP 文件 - 它的唯一作用是：当你已有部分 polyfill 时，
composer update可能顺带补全遗漏项；新项目请直接跳过它 - 真正生效的子包，比如
symfony/polyfill-php80，在自己的composer.json中明确写了"autoload": {"files": ["bootstrap.php"]}
怎么选对子包：别信文档写的“PHP 7.3+”，查实际归属
同一个函数，在不同版本的 polyfill 包里可能根本不在一个地方。装错包，函数就永远找不到。
-
mb_str_split()虽然出现在 PHP 7.3，但它被归入symfony/polyfill-php80—— 不是php73，装后者无效 -
json_validate()同理，官方语义上属于 PHP 8.0 特性，必须装symfony/polyfill-php80，哪怕你用的是 PHP 7.4 - 用了
IntlCalendar::createInstance()却缺ext-intl？得同时装symfony/polyfill-intl-idn和symfony/polyfill-intl-normalizer，单装一个不行 - 不确定该装哪个？先看报错函数名，再查 symfony/polyfill 的各子包 README，或直接搜源码里的函数定义位置
函数还是不存在？检查 autoload.files 是否真被加载
子包装好了，bootstrap.php 也存在，但函数仍报错——大概率是自动加载链断了。
- 确认文件存在：
vendor/symfony/polyfill-php80/bootstrap.php（路径按你装的包名变） - 确认它进了 Composer 加载列表：运行
composer dump-autoload -o，然后打开vendor/composer/autoload_files.php，找对应路径是否在数组里 - 确保项目入口第一行是
require __DIR__.'/vendor/autoload.php';，且只引入一次；微框架（如 Slim）或自定义 autoloader 可能忽略autoload.files，需额外配置 - 千万别手动
require 'vendor/symfony/polyfill-php80/bootstrap.php'—— 这会绕过function_exists()检测，导致重复定义警告，或原生函数被错误覆盖
测试是否生效：别在定义前做 function_exists 检查
polyfill 的 bootstrap.php 是“懒加载”的：它只在第一次调用目标函数时才执行并定义函数。这意味着：
- 如果代码在调用
str_starts_with()前就执行了function_exists('str_starts_with')，结果一定是false—— 这不是 bug，是设计 - 验证是否生效，最可靠的方式是：直接调用该函数，或在调用后立刻
var_dump(function_exists('str_starts_with')) - 单元测试里若依赖提前检测，建议改用
class_exists()或defined()（针对常量）等更稳定的判断方式
最容易被忽略的点是：polyfill 不是“静态注入”，而是靠运行时探测 + 懒加载触发；你看到的报错，90% 出现在加载链断裂或子包选错这两个环节，而不是 polyfill 本身不可靠。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
