最可靠方式是直接调用 json_encode($item) 并检查返回值不为 false 且 json_last_error() === JSON_ERROR_NONE；需清零错误码、逐项测试、不可依赖类型判断或 JSON_PARTIAL_OUTPUT_ON_ERROR。
如何判断一个 PHP 数组元素是否能被 json_encode() 正确序列化
直接用 json_encode() 尝试编码并检查返回值是否为 false 是最可靠的方式。PHP 不提供预检函数，所以不能靠类型判断（比如“只要不是 resource 就行”），因为对象可能有不可序列化的属性、递归引用、或实现了 JsonSerializable 但抛出异常。
常见错误现象：json_encode() 返回空字符串或 false，且 json_last_error() 返回 JSON_ERROR_UNSUPPORTED_TYPE、JSON_ERROR_RECURSION 或 JSON_ERROR_INF_OR_NAN。
- 对每个待筛选的元素单独调用
json_encode($item)，不要传整个大数组进去再过滤 —— 这样无法定位具体哪个元素失败 - 必须配合
json_last_error() === JSON_ERROR_NONE判断，仅检查返回值是否为false不够（例如空数组编码后是"[]"，不是false） - 浮点数需额外注意：
INF、-INF、NAN在 PHP 8.0+ 默认触发JSON_ERROR_INF_OR_NAN，即使开启JSON_PARTIAL_OUTPUT_ON_ERROR也只会转成null，但你通常希望提前剔除它们
批量筛选含无效元素的关联数组（如 API 响应数据）
典型场景：从数据库或外部接口拿到一个混合结构的 $data 数组，其中某些字段可能是 Closure、resource、带循环引用的对象，需要安全地提取出可 JSON 化的子集。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用
array_filter()配合匿名函数逐项测试，避免修改原数组结构（如用foreach+unset()易出键错乱） - 对嵌套结构，不推荐递归全量预检（性能差、易栈溢出），应按需处理：只对明确要输出的字段路径做校验，比如只筛
$data['items']而非整个$data - 若元素是对象，优先检查是否实现
JsonSerializable接口，但依然要执行json_encode()实测 —— 接口实现可能内部 throw Exception
示例：
$safe_items = array_filter($data['items'], function ($item) {
$encoded = json_encode($item);
return $encoded !== false && json_last_error() === JSON_ERROR_NONE;
});
JSON_PARTIAL_OUTPUT_ON_ERROR 能否替代主动筛选？
不能依赖它来“兜底”。该 flag 只影响编码行为（把不可序列化值转成 null），不改变筛选逻辑本身。
问题在于：
- 它无法告诉你哪个位置被静默替换，调试困难
- 对于
resource或闭包，它确实转成null，但你通常需要报错或跳过，而不是留下一个语义丢失的null - 在 PHP 7.3+ 中，它对
INF/NAN生效，但对循环引用仍报错（JSON_ERROR_RECURSION），不统一 - 开启后，
json_encode()即使出错也不返回false，导致你无法用返回值判断成败
为什么不要用 is_scalar() 或 gettype() 做预过滤？
看似简单快捷，实际漏判严重。例如：
-
is_scalar(null)是false，但null完全合法（JSON 中对应null） -
is_scalar($obj)对对象返回false，但很多对象可被正常编码（如标准类、实现JsonSerializable的类） -
gettype($resource)是"resource"，但你无法仅凭类型知道它是否被某个扩展标记为可序列化（极少数情况） - 数组里有
NaN浮点数时，gettype(NAN)返回"double"，看起来完全正常，却会导致编码失败
真正有效的筛选只能基于 json_encode() 的实际执行结果，没有捷径。
最常被忽略的一点：编码前记得调用 json_last_error() 清零 —— 如果之前某次编码失败没检查，残留错误码会影响本次判断。
