PHP 5.6以下不支持array_column()，需用自定义函数兜底；PHP 5.3不支持json_last_error_msg()，需手动映射错误码；PHP 5.2的mb_strtolower()不支持$encoding参数，应提前设置默认编码。
PHP 5.6 以下不支持 array_column() 怎么办
这个函数在 PHP 5.5 及更早版本根本不存在，直接调用会报 Fatal error: Call to undefined function array_column()。别急着升级环境，先用原生循环兜底。
常见场景是提取二维数组中某字段值（比如从用户列表里取所有 id）：
function array_column_fallback($input, $column_key, $index_key = null) {
$result = array();
foreach ($input as $row) {
if (!is_array($row)) continue;
$value = $column_key === null ? $row : $row[$column_key];
if ($index_key !== null && isset($row[$index_key])) {
$result[$row[$index_key]] = $value;
} else {
$result[] = $value;
}
}
return $result;
}- 注意判断
$row是否为数组，避免Notice: Undefined index - 如果原始数据含非数组项（如
null或字符串），跳过可防崩溃 - 该实现不完全等价于 PHP 7+ 的
array_column()（比如对对象支持弱），但覆盖 95% 的数组提取需求
PHP 5.3 不支持 json_last_error_msg() 怎么获取 JSON 错误信息
PHP 5.4 才引入这个函数，旧版只能靠 json_last_error() 返回码硬查。手动映射比临时升级 PHP 更快。
错误码含义没变，只是没封装成字符串：
立即学习“PHP免费学习笔记（深入）”；
$json = json_decode($str, true);
if (json_last_error() !== JSON_ERROR_NONE) {
$errors = array(
JSON_ERROR_DEPTH => 'Maximum stack depth exceeded',
JSON_ERROR_STATE_MISMATCH => 'State mismatch (invalid or malformed JSON)',
JSON_ERROR_CTRL_CHAR => 'Control character error, possibly incorrectly encoded',
JSON_ERROR_SYNTAX => 'Syntax error',
// 其他按需补全，完整列表见 PHP 手册 JSON_ERROR_* 常量
);
$msg = isset($errors[json_last_error()]) ? $errors[json_last_error()] : 'Unknown error';
throw new Exception('JSON decode failed: ' . $msg);
}- 不必全量定义所有常量，日常开发遇到最多的是
JSON_ERROR_SYNTAX（格式错）和JSON_ERROR_CTRL_CHAR（UTF-8 BOM 或非法字符） - 别漏掉
JSON_ERROR_NONE判断，否则会把正常解析误判为失败 - 如果项目已用 Composer，可引入
symfony/polyfill-json自动打补丁，但纯函数替代更轻量
PHP 5.2 里 mb_strtolower() 缺少 $encoding 参数怎么办
PHP 5.2 的 mb_strtolower() 只接受一个参数，不支持指定编码。若你传了第二个参数（如 mb_strtolower($str, 'UTF-8')），会警告 Warning: mb_strtolower() expects exactly 1 parameter。
解决办法不是删参数，而是提前设置默认编码：
if (version_compare(PHP_VERSION, '5.3', '<')) {
mb_internal_encoding('UTF-8');
}
// 后续所有 mb_* 函数都按 UTF-8 处理
$lower = mb_strtolower($str);- 必须在首次调用任何
mb_*函数前设置，否则无效 - 如果项目混用多种编码（比如 DB 是 GBK、接口是 UTF-8），不能全局设死，得改用
iconv()+strtolower()组合 -
mb_internal_encoding()在 PHP 5.2.7+ 才稳定，低于此版本建议直接切到iconv('UTF-8', 'UTF-8//IGNORE', $str)再小写
为什么有些“兼容写法”上线后反而出问题
最常被忽略的不是函数有没有，而是行为差异。比如：
-
array_merge()在 PHP 5.0–5.2 对数字键处理更激进，会重排索引；新版保留原键 —— 如果你依赖键名做逻辑，光替换函数没用 -
empty()在 PHP 5.5+ 对未定义数组键返回true，而旧版可能报Notice；加@抑制不是解法，应先用isset()或array_key_exists() - 第三方 polyfill 库（如
paragonie/sodium_compat）虽能模拟新函数，但性能下降明显，高频调用场景要压测
兼容的本质是控制变量：先确认最低运行版本，再逐个验证函数行为，而不是只看是否存在。
