function_exists 只检测当前作用域中是否已声明函数，不跨命名空间隐式查找，需传完整命名空间名；对未加载、禁用、非函数语法（如类方法）均返回 false，不能替代 is_callable 或 extension_loaded。
用 function_exists 检测函数前，先确认作用域是否正确
PHP 的 function_exists 只检查当前作用域下是否已声明（或自动加载）该函数，不跨命名空间隐式查找。比如你在 App\Utils 命名空间里写了 format_date()，直接传字符串 "format_date" 给 function_exists 会返回 false —— 它不认识命名空间前缀。
实操建议：
- 检测用户自定义函数时，确保传入的是完整函数名（含命名空间），例如
function_exists('App\Utils\format_date') - 检测内置函数（如
json_encode、mb_strlen）可直接用函数名字符串，无需引号加反斜杠 - 如果函数由 Composer 自动加载，且尚未被加载过，
function_exists会返回false，哪怕它“逻辑上存在”——这不是 bug，是 PHP 加载机制决定的
function_exists 和 is_callable 别混用
function_exists 只回答“这个函数名有没有被定义”，不管它能不能调用；而 is_callable 还会检查访问权限（比如 private 方法）、是否被禁用（disable_functions 配置）、甚至能识别数组回调和对象方法。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 用
function_exists('exec')返回true，但实际运行exec('ls')报错：因为exec被disable_functions屏蔽了 - 检测一个类的静态方法时写成
function_exists('MyClass::doSomething')—— 这永远是false，因为这不是函数名，是回调语法
该用哪个？
- 只关心“有没有这个函数定义”，比如做兼容性降级判断，用
function_exists - 想确认“现在立刻能安全调用”，尤其涉及动态回调、用户输入拼接的函数名，必须用
is_callable
扩展未启用时，function_exists 是最轻量的兜底判断
比如项目里想用 imagick 处理图片，但服务器可能没装扩展。比起直接 new Imagick() 然后 try/catch，先用 function_exists('Imagick::__construct') 或更稳妥地查一个典型函数如 function_exists('ImagickDraw::setFillColor')，能提前退出，避免实例化失败带来的开销。
注意点：
- 不要查构造函数名（
__construct）来判断类是否存在——function_exists对魔术方法无效，得用class_exists - 查扩展函数时，选一个**非别名、非废弃、扩展一启用就可用**的函数，比如
gd_info比imagecreate更稳（后者在某些 GD 编译配置下可能被关掉） - 别在循环里反复调用
function_exists查同一个函数——结果不会变，缓存起来就行
替代方案：用 extension_loaded 更准，但粒度更粗
如果目标只是确认某个扩展是否可用（比如 curl、redis），extension_loaded('curl') 比查具体函数更可靠：它不依赖函数是否被禁用，也不受自动加载影响，直接读 PHP 的扩展注册表。
但要注意：
- 有些扩展提供多个函数，但名字不统一（比如
memcached扩展导出的是Memcached类，不是一堆函数），这时extension_loaded是唯一靠谱方式 -
extension_loaded返回true不代表所有函数都能用——比如opcache扩展开了，但opcache_get_status()可能因配置被禁用，仍需配合function_exists或is_callable - Windows 下扩展名带
.dll，Linux/macOS 是.so，但extension_loaded参数只写扩展名（如'mbstring'），不用加后缀
真正容易被忽略的是：函数存在 ≠ 能用，能用 ≠ 有权限，有权限 ≠ 配置允许。一次 function_exists 只解决其中一环，别让它背太多锅。
