会，PHP 7.2 的 json_decode() 因全量加载机制和默认512层嵌套限制，解析几十MB以上或深层嵌套JSON时极易内存溢出，实际内存占用可达文件体积的5–20倍，并可能触发JSON_ERROR_DEPTH或OOM崩溃。
会，PHP 7.2 使用 json_decode() 解析大 JSON 对象时极容易出现内存溢出，尤其当数据体积达几十 MB 以上或嵌套过深时。
核心原因有两个层面：
全量加载机制：
json_decode()必须将整个 JSON 字符串一次性解析为完整的 PHP 数据结构（如嵌套数组或对象）。每个字符串、数组、对象在 PHP 内部都对应一个zval结构，含引用计数、类型标记、哈希表等开销。100MB 的 JSON 文件，实际内存占用常达 500MB–2GB+，远超文件本身大小。-
默认深度限制与栈压力：PHP 7.2 默认最大嵌套深度为 512 层。若 JSON 存在深层嵌套（如
{"a":{"b":{"c":{...}}}}），即使未超限，递归解析过程也会持续压栈、分配内存；一旦接近极限，可能触发JSON_ERROR_DEPTH错误，或更隐蔽地引发内存碎片化和 OOM 崩溃。立即学习“PHP免费学习笔记（深入）”；
常见触发场景包括：
- 用
file_get_contents()读取几百 MB 的商品列表 JSON 后直接json_decode($json, true) - 解析上游返回的单个巨型对象（如
{"data": [...10万条记录...]}） - 处理日志导出文件却误判为“单 JSON”，实际是 NDJSON（每行一个 JSON）
验证是否真由 json_decode 导致：
echo 'Before: ' . memory_get_usage(true) . "\n";
$json = file_get_contents('huge.json');
echo 'After read: ' . memory_get_usage(true) . "\n"; // 此处已飙升
$data = json_decode($json, true);
echo 'After decode: ' . memory_get_usage(true) . "\n"; // 再翻倍不建议的缓解方式：
- 单纯调高
memory_limit（如设为2G）——治标不治本，且存在服务级风险 - 手动
substr分块 + 拼接 JSON 片段——极易破坏结构完整性，语法错误率高
可行的替代方案：
- ✅ 若是 NDJSON / JSONL 格式（每行一个独立 JSON）：用
fopen()+fgets()流式逐行读取，每行调用json_decode($line, true) - ✅ 若需提取 特定字段（如所有
users[].name）：改用流式解析器，如pcrov/jsonreader或cerbero/json-parser，内存占用稳定在几 MB 级别 - ✅ 若可控制上游：推动改为分页 API 或 CSV/Parquet 等更高效格式，避免传输巨型 JSON
PHP 7.2 本身不支持 json_validate()（PHP 8.3+）或 JSON_THROW_ON_ERROR（PHP 7.3+），因此务必手动检查：
$result = json_decode($json, true);
if ($result === null && json_last_error() !== JSON_ERROR_NONE) {
throw new RuntimeException('JSON parse error: ' . json_last_error_msg());
}本质上，这不是 PHP 7.2 的 bug，而是 json_decode 设计定位决定的——它面向中小规模、结构可信的配置类数据，不适合大数据管道场景。
