直接用 function_exists 即可，它已可靠判断函数是否声明，自行封装易引入误判；需注意其不检查可用性、不可用于类方法或常量，仅当聚合多函数检测时才建议语义化封装。
直接用 function_exists 就行，别自己封装
PHP 原生的 function_exists 已经足够可靠，能准确判断当前运行环境中是否定义了某个函数（包括扩展函数、用户自定义函数、甚至被 unset() 过的函数）。自己再包一层不仅没增益，反而容易引入误判——比如漏掉大小写敏感性、或错误处理边界。
常见误操作是写成：if (my_function_exists('json_encode')) { ... }，结果多一层调用栈、多一次字符串参数传递，还可能因缓存逻辑不一致导致行为偏差。
function_exists 的真实行为和限制
它只检查函数是否「已声明」，不关心是否可用（例如扩展已加载但函数被 disable_functions 屏蔽）；也不检查是否可调用（如 private 方法、重载失败的魔术方法）。
-
function_exists('curl_init')返回true，不代表 cURL 扩展能实际发起请求（可能 DNS 失败、SSL 证书问题） -
function_exists('gzcompress')返回false，大概率是 zlib 扩展未启用，不是函数名拼错 - 对命名空间函数（如
\DateTime::createFromFormat），要传完整限定名：function_exists('date_create_from_format')—— 注意这是全局函数名，不是类方法名 - 不能用于检测类方法，得用
method_exists；也不能检测常量，得用defined
真正需要“封装”的场景：兼容性兜底 + 可读性增强
如果你反复判断同一组函数是否存在（比如一连串 JSON 相关函数），或者想让条件更语义化（如 has_json_support()），那可以封装，但目的不是“替代 function_exists”，而是聚合逻辑。
立即学习“PHP免费学习笔记（深入）”；
示例：
function has_json_support(): bool
{
return function_exists('json_encode')
&& function_exists('json_decode')
&& function_exists('json_last_error');
}
这种封装有意义，因为：
- 把多个
function_exists调用合并为一个语义明确的判断 - 后续若需补充判断（如检查
JSON_THROW_ON_ERROR常量），只需改一处 - 避免在业务逻辑里散落一堆裸的
function_exists调用，降低维护成本
容易踩的坑：大小写、拼写、扩展状态
PHP 函数名是大小写不敏感的，function_exists('JSON_ENCODE') 和 function_exists('json_encode') 结果一样。但人容易手抖拼错，尤其是带下划线或驼峰风格的函数（比如把 mb_strtolower 写成 mb_strtolower）。
更隐蔽的问题是扩展存在但被禁用：
- 即使
extension_loaded('mbstring')返回true，function_exists('mb_strlen')仍可能为false（如果 php.ini 中设置了disable_functions = mb_strlen） -
function_exists不会报错，也不会触发 warning，返回false是唯一信号——必须靠你主动检查并处理降级逻辑 - 某些函数（如
apache_get_modules）只在 Apache SAPI 下存在，CLI 或 FPM 下必然返回false，这不是 bug，是环境差异
真正复杂的点在于：函数存在 ≠ 功能可用 ≠ 行为符合预期。别只卡在“有没有”这一步，后续调用时的错误码（如 json_last_error()）、异常抛出、返回值类型变化，才是更常出问题的地方。
